staging-devopsy.kinsta.cloud

Tag: devsecops

  • build.security Leverages OPA to Shift App Authorization Left

    build.security Leverages OPA to Shift App Authorization Left

    build.security today announced it has raised $6 million to launch a platform that promises to make it simpler for developers to centralize the management of authorization controls across multiple applications.

    The goal is to enable DevOps teams to shift control over application authorization further left to advance adoption of best DevSecOps practices using a platform based on the open source Open Policy Agent (OPA) software, which enables developers to create policies that manage authorization as code.

    Company CEO Amit Kanfer said every application deployed today requires its own unique set of authorization requirements based on roles, permission models and complex hierarchies along with relevant identity, resource and context attributes. Streamlining that process requires a platform that provides a uniform approach to managing that process that is more flexible than existing approaches based on either role-based access controls (RBAC) or attribute-based access controls, said Kanfer.

    Otherwise, developers are required to build an array of complex authorization models, policy engines and enforcement points themselves to manage identities, resources and attributes. Those tasks are not only time-consuming but also highly prone to errors that leave applications vulnerable to cyberattacks. he said.

    OPA makes it easier for developers to implement fine-grained access controls using a drag-and-drop interface that decouples authorization policy from code. That approach makes it easier to declaratively make changes and updates to applications over time as more end users are added or removed, Kanfer said.

    Designed to be deployed on-premises or in the cloud, the authorization platform also provides integrations with identity providers, databases and other services that expose application programming interfaces (APIs). It will also automatically generate policy suggestions based on the runtime interactions between services.

    Historically, authorization to access applications has been poorly managed because it’s been difficult to manage manually. Business leaders are supposed to inform IT organizations when to add and delete end users. In practice, they often forget, resulting in end users still having access to applications long after they have left the company. Even when IT is informed that an end user has left a company, it can take a day for the end user to be deleted from all the applications they have been granted access over the span of their career at that organization. Shifting control over authorization left toward developers creates an opportunity to automate a process that is often haphazard at best.

    It also should allow organizations to reduce their dependency on Microsoft Active Directory (AD), which many organizations have employed to manage access to applications and files in Windows environments in favor of a centralized approach that can be more broadly applied to multiple applications.

    Authorization management may not always be at the top of the IT management agenda. However, at a time when cybercriminals are stealing credentials with more abandon than ever, the time may have finally come for IT organizations to reconsider how those credentials are managed and updated. After all, based on the number of data breaches involving stolen credentials, current approaches are clearly not working.

  • Two-Part Training Required for Developers to Slay the Security Beast

    Two-Part Training Required for Developers to Slay the Security Beast

    Developers’ defensive qualities are only as good as the training they receive

    The playing field between the heroes and villains in cybersecurity is notoriously unfair. Sensitive data is the new gold, and attackers adapt quickly to circumvent defenses, exploiting security bugs large and small for potential paydirt.

    The volume of code being produced is too great for security experts—who are becoming increasingly scarce—to contend with, and the rising cost of data breaches is proof that something has got to give. Fortunately, for the sake of our digital safety and the sanity of CISOs everywhere, the DevSecOps movement is helping to bring developers on the security journey from the beginning of the software development process. They are being recognized as the first line of defense against cyberattackers, with the power to eliminate common vulnerabilities at their fingertips.

    However, their defensive capabilities are only as good as the training they receive, and that is yet another gauntlet for security teams to run. For many developers receiving on-the-job training in secure coding, their key challenge is staying awake during mind-numbing, hands-off activities that are neither effective nor inspiring them to keep security front of mind. Soulless video courses aren’t getting us there, token annual ‘tick-the-box’ events are a waste of time, and nobody is winning against the potential malicious threat actor waiting to jump on a small window of opportunity.

    At this stage in our industry, we have worked out that contextual, hands-on education that is delivered in relevant programming languages and frameworks, with challenges that mimic those a developer might come across in the real world, is a far more engaging approach.

    This is phase one of a developer’s quest to help AppSec gurus slay common vulnerabilities, but phase two is where scenarios must get real for a supercharged, security-aware defensive force.

    Scaffolded Learning Is Critical in Adult Education

    When it comes to extracurricular courses or on-the-job training, it is often overlooked that adults bring with them a certain level of experience and existing knowledge. Good training adds to this foundation and is structured in a way that allows for deeper understanding and faster autonomy in the learning process.

    Scaffolded education is a potent, positive method of learning that seeks to activate and enhance prior experience while continuing to build new skills—in manageable chunks—that allow the learner to tackle increasingly difficult tasks with more confidence. Typically, it is a methodology best served with healthy portions of demonstration, visual aids and student-led exploration.

    If we tie this approach back to developer security training, it comes as no surprise that the dynamic, learn-by-doing method has long been preferred over the drudgery that is theory-based static learning. They are free to be the masters of their domain and should see that their time is being well-spent.

    In that sense, learning to code securely in a hyper-relevant, contextual environment is key, but the ‘level up’ from this step is to see an exploit of vulnerable code in action. With the context of front-end and back-end views side-by-side, there is a tangible link between actions taken during the coding process and what an attacker can potentially do with cut corners, misconfigurations or accidents that are not caught and remedied.

    Move From Recall to Application for a Truly Preventative Security Approach

    Experiencing the impact of security vulnerabilities firsthand is a vital piece of the education puzzle, and it’s a fairly rare beast, even with the most modern security training options for developers. The foundational work spent on honing skills in spotting and remediating vulnerabilities and recalling that experience to eliminate the same bugs in code as it is being written is extremely important, but it’s not the whole picture. Seeing how vulnerable code is exploited by a malicious actor adds a powerful layer of context, one that really drives home the importance of securing code and applying hard-earned security knowledge to close every window of opportunity.

    It is generally accepted that developers don’t love security, and they have even less affection for security training. Their experiences with AppSec specialists can be very frosty, and the rework caused by the security team bouncing vulnerable code back to developers for remediation is the bane of their existence. To an engineering team that is already spread thin, security is someone else’s problem, not their priority, and a hindrance to their natural creativity and primary objective of building features. However, there is simply too much code, too many breaches and too much risk to the world’s data for this mindset to continue.

    A functional DevSecOps process has developers working in harmony with security teams right at the beginning of the software delivery life cycle (SDLC). Likewise, the opportunity for applied learning, where they can interact with a simulated exploit and see the impact of poorly secured code, goes a long way in getting developers on the same page as those pesky AppSec people (who aren’t so bad after all).

    Interactive Learning Prepares Developers for the Boss Fight

    At the time of writing, there were two major breaches reported in a seven-day period: Razer announced that more than 100,000 sensitive data records had been exposed, while office supplies retailer Staples also reported a similar data leak. More than a billion sensitive records have been exposed so far in 2020, and this worrying trend shows no signs of slowing down. Simply put, malicious actors have the upper hand and security-aware developers are sorely needed to serve as the front line of defense.

    Interactive challenges that focus on simulating such breaches move developers from passive recall, to applying skills that have an impact on the real boss fight: stopping attackers in their tracks.

  • DevSecOps Implementation: Static Analysis

    DevSecOps Implementation: Static Analysis

    One of the things I’ve done for Accelerated Strategies Group recently is looking into DevSecOps toolsets. This is a fun area for me, as development and security fit together well in my mind. Having a separate security group is useful, even necessary in some scenarios, but letting developers crank out code and looking for vulnerabilities only after has always seemed terribly inefficient. Whenever I’ve managed developers, security training is just part of the package I bring. It’s far easier to write it well the first time (the equivalent of shift-left) than rewrite it.

    I won’t name names here—this is work I did for ASG, it is not mine to give away—but I will talk about DevSecOps today, and moving into the future. I’m planning three to four installments for this series, discussing the different aspects of DevSecOps tools.

    For clarity, we’re defining DevSecOps tools as “developer-enabled security tools.” This means that in some way, they help developers improve overall security posture while leaving them to be developers. We all know security has to shift left in every way if it’s to be useful in a DevOps world, but most organizations haven’t seriously started the move to shift security. Hopefully, this series helps.

    Depending upon which financial analyst firm you prefer, projections are that the DevSecOps market will grow 28% to 33% a year for the next few years. While this is good news for DevSecOps vendors, it implies very few organizations have systemically adopted DevSecOps, or there would not be room for that level of growth.

    Whether a traditional team or a DevOps team, the static analysis portion of DevSecOps is (generally) easy to set up and configure and most products offer feedback at both coding time and build time. IDE plugins have come a long way, some even offering advice as-you-code and others allowing developers to run on-demand static scans of their work. The industry as a whole has worked hard to lower the false-positive rates that made most organizations reluctant to deploy them broadly, and prioritization of issues is possible in the best products, making identification and remediation pretty easy. Try a pilot out: Pick a vendor and project, grab the IDE plug-in and check out what they can do. Most do not yet directly support code smells, but I suspect that is coming rapidly, as the systems are already designed to look at source and determine issues. Adding to the collection of possible issues will be a differentiator that quickly turns into a market requirement.

    Things to check for:

    • Language support: Do the languages you use have a scanner? While most of the tools on the market offer support for a breadth of languages, there are differences, so check the corner cases. This truly is a make or break decision—the best product on the market is useless to your org if it doesn’t support the languages you use.
    • IDE integration: This is pretty straightforward, are the IDEs your developers use day in and day out supported? Most of these tools offer command-line variants also, so it is possible that even without support directly in the IDE, the security functionality of a given product dictates that command-line is better. In that scenario, a process to ensure developers are even running scans is a good idea.
    • Vulnerabilities detected: At a minimum, support for whatever is currently in the National Vulnerability Database (NVD) should be required, along with OWASP compliance. Most vendors offer support beyond the NVD, so a bit of research to see what types of vulnerabilities are detected will be in order.
    • Click-through support: With IDE plug-ins, one of the great strengths of scanning is the ability of the developer to simply click on the vulnerability in the results list and go to the offending code. Make certain this works—and works as advertised.
    • False-positive rate: This has historically been a problem, but the industry has brought it down overall. Ask your prospective vendors to share their numbers. Our experience shows low single-digits for a percent, which is far better than the past, but still leaves room for improvement.

    The other part of static analysis is plugging static analysis into the build process. Most of these products have integrations into the most popular build management tools. Scanning the entirety of the application allows the static analysis to see a broader vision of the app and note issues with interactions between portions written by different developers. Reporting for build-time scans is generally at the application/team level, and the best tools will show results of development-time scans side by side with build-time scans if you want them to.

    Things to check for:

    • Language support: Again with the languages. It’s pretty simple here: The core of the application may be built using languages a given vendor supports but critical parts might not. Integration is where that becomes a real issue. Make sure what needs scanning can get scanned.
    • Integrations: Most of these tools offer automated scans through integration with build tools or manual scans that the build manager can kick off. Automation is preferred by a long shot, so check if your tool of choice is integrated into your organization’s build tooling.
    • Depth: We’re not going to get into source composition analysis (SCA) here—that’s for another blog—but we are going to observe that vulnerabilities can come from your source’s sources. How far does the scanning tool trace in a static analysis situation? Is it deep enough to cover a given application’s integrations and inter-relationships? While SCA will detect a lot that static scanning won’t, things such as “unsafe values sent to [insert external API]” should be available in static code analysis.
    • Reporting: This is where you’ll find the most variety in popular tools. Look at their reporting and click-through support to find what best suits your needs.
    • False-positive rate: Same as IDE integrations above—make certain it is low enough for your organization’s comfort.
    • Scan run location: This is becoming a differentiator in the space—do you want your scans run in the cloud? In the data center? Some mix of both? Check your vendors; there are significant differences in the level of support for these options.

    This is just the tip of the iceberg, of course. It is an entire market segment, and static analysis tools have been around a long time. Many organizations have not taken dev-time security seriously yet, even though we all know we need to; I’m just offering a place to get started.

    DevSecOps just makes sense. Static scanning is mature and generally well-integrated. This is a great place to start shifting security left. We get it: Developers don’t want to be security analysts or they’d have filled one of those many security openings. But IDE integration makes these scanning tools more interactive and less intrusive, showing developers how to do it securely as they code. This is great to me because good coding practices will become second nature with real-time, on-the-spot reminders and pointers. It also means that if the developer acts upon the tool’s recommendations, the code is developed more securely the first time and there will be no need to revisit it for security proofing.

    You’re all keeping the lights on in a terribly tough time. DevSecOps attempts to make it more likely that your astounding work isn’t interrupted. It just makes sense to get these tools to protect your organization’s portfolio and your hard work.

  • ZeroNorth Adds Security Defect Density Dashboard

    ZeroNorth Adds Security Defect Density Dashboard

    ZeroNorth today announced it has added a Defect Density Dashboard to its software-as-a-service (SaaS) platform for managing and orchestrating application security scans.

    Company CEO John Worrall said Defect Density Dashboard borrows a concept employed to measure software quality and applies it specifically to application security. The dashboard surfaces the number of application security defects per thousand lines of code discovered during scans of code made using software composition analysis (SCA) and software application security testing (SAST) tools.

    That metric will create a key performance indicator that application security champions within DevOps teams and chief information security officers (CISO) can use to quantitatively measure the progress being made toward improving overall application security, he said.

    As organizations begin to adopt best DevSecOps practices Worral said one of the challenges IT leaders face is showing the board of directors that the level of investment being made is delivering measurable results. The Defect Density metric applies a concept that is already widely employed by quality assurance teams in manufacturing and other vertical industries to software development, he noted.

    As a provider of a SaaS platform for orchestrating security scans across multiple third-party tools, Worral said ZeroNorth is in the unique position of being able to normalize all the data generated by the tools.

    The Defect Density Dashboard also makes it easier to identify specific areas of weakness such as larger numbers of SQL injection vulnerabilities that would indicate a need to make additional training available to software development teams, he added, noting that approach allows the application security advocate to be viewed as an ally versus someone who merely criticizes the efforts of a software development team.

    Encouraging developers to scan their code before they make a commit is, of course, at the heart of any effort to shift more responsibility for application security to the left. ZeroNorth has been making a case for a platform that makes it easier to implement multiple scans across a DevOps workflow using different tools. That approach makes it more likely that a vulnerability that isn’t discovered by one tool is uncovered by another.

    The challenge, of course, is making sure developers scan their code often. There is a natural tendency to delay a scan in the name of productivity. However, the larger the base of code that needs to be scanned, the longer it takes to complete those scans. Most developers would be well-advised to scan smaller amounts of code more often.

    Regardless of the approach to scanning, developers should expect to be evaluated based on the number of vulnerabilities that are inadvertently introduced into their code. Cybersecurity teams can no longer keep pace with the rate at which application code is being deployed and updated. As such, many organizations have launched a concerted effort to eliminate as many vulnerabilities as possible before code gets deployed in a production environment. It may never be possible to eliminate 100% of vulnerabilities, but at the very least the most common exploits that cybercriminals actively scan for when looking to compromise an application can be greatly reduced.

  • Survey Sees Long DevSecOps Ahead

    Survey Sees Long DevSecOps Ahead

    A survey of 250 developers working at leading technology companies paints a bleak picture of the current state of application security with 85% admitting applications on average have 10 or more vulnerabilities, with nearly half saying they have on average more than 20 per application.

    Conducted by Contrast Security, a provider of an observability platform for security, the survey also finds nearly 50% of application security tools are not integrated into the continuous integration/continuous delivery (CI/CD) pipelines.

    Contrast Security CTO Jeff Williams said it’s clear most organizations have a long way to go before best DevSecOps practices become commonplace. In the meantime, the level of disruption being caused by the need to remediate vulnerabilities remains high. The survey finds 88% of respondents need to stop development work to remediate vulnerabilities at least once a week, with nearly 80% spending too much time triaging and diagnosing application security alerts.

    Nearly three-quarters of respondents also noted their organizations cannot find highly specialized application security experts.

    On the plus side, more than one-third of respondents (36%) said at least one application security metric is among their top four performance measurements. Most (63%) have also deployed an interactive application security testing (IAST) solution.

    Most importantly, 77% of respondents said they want more application security training.

    Williams said ultimately DevSecOps will require an observability platform capable of capturing metrics that are meaningful to developers. Contrast has launched an observability platform for IT security teams that borrows DevOps principles to streamline the management of cybersecurity.

    Achieving and maintaining security is complex because application data flows in and out of disparate systems running in the cloud and on-premises IT environments. IT security teams are forced to navigate a multitude of application programming interfaces (APIs) that have varying degrees of dependencies to ascertain what’s actually occurring in their extended IT environments.

    Contrast enables DevOps teams to instrument their applications with security sensors, which Williams said enables the Contrast Application Security Platform to aggregate data flows spanning multiple applications. That approach also eliminates silos spanning application security testing (AST), software composition analysis (SCA) and runtime application self-protection (RASP) tools installed across an enterprise, said Williams.

    It’s not clear to what degree DevOps teams will add agents specifically to instrument applications to gather security data. However, as more responsibility for application security is shifted left toward developers, it’s apparent legacy approaches to securing applications are being found wanting.

    In the meantime, it’s still early days as far as DevSecOps is concerned even for technology companies, much less the average enterprise. Most IT organizations are just getting started down this path. The issue most of them are coming to terms with is the degree to which they need their DevOps and cybersecurity teams to collaborate. While there may be a need for a lot of interaction between these two teams early on, there may come a day soon when DevOps teams eventually reach a level of proficiency that makes security a natural extension of any quality assurance process.

  • Survey Finds Security Champions Fostering DevSecOps

    Survey Finds Security Champions Fostering DevSecOps

    A survey of 99 application development and IT security professionals suggests organizations that appoint a security champion within their application development teams are making more progress toward implementing best DevSecOps practices.

    According to the survey conducted by ZeroNorth, a provider of an application security automation and orchestration platform, 84% of respondents said they believe the efforts of dedicated security champions have both bolstered application security (AppSec) and improved relationships between security and DevOps teams.

    More than two-thirds of respondents (67%) said a security champion initiative has existed in their organizations for less than two years, with almost 40% reporting an initiative being in place for less than one year.

    Among respondents from organizations that have such programs, 78% of respondents said the program has strengthened the security skills and knowledge of developers, with 77% reporting their organization’s overall AppSec posture has improved. Half of the respondents (50%) noted having a passion for security is a characteristic of any successful security champion.

    More than half of respondents (56%) said support from corporate security leadership was a top requirement for the success of security champion, while 47% said support from engineering leadership was also required.

    In addition, 57% of survey respondents said corporate security teams should also play a role in defining security priorities, while 47% said they should be involved in training best practices.

    ZeroNorth CEO John Worrall said the survey results show security champions within application development teams are becoming a unifying force that drives increased levels of collaboration between DevOps and security teams. In effect, the security champion functions as an ambassador for the security teams among developers, who typically don’t have a lot of security expertise, he noted.

    At the same time, security champions within application development teams increase the confidence security professionals have in developers as responsibility for AppSec shifts further left toward DevOps teams, Worrall said.

    Collaboration between those teams is more critical than ever as organizations embark on digital business transformation initiatives that are likely to become primary targets of cybercriminals, who increasingly are focusing their efforts on high-value targets, he added. The challenge now is finding a way to automate DevSecOps workflows to make sure that the rate at which those applications are being developed is not impeded by manual security reviews or security scans that take too long to run, said Worrall.

    The level of progress organizations are making toward embracing best DevSecOps practices is, of course, uneven. However, it’s become apparent that continuing to rely on understaffed security teams to review applications for security flaws before they are deployed in a production environment is no longer practical. But finding a security champion with the appropriate level of application development expertise is no easy task. Merely adding someone from the security team into a DevOps team isn’t likely to succeed if that individual has no development experience. In fact, it’s often easier to teach developers about security than it is to teach cybersecurity professionals how to code. The issue is finding a developer whoDev has a zeal for security that is contagious enough for the whole DevOps team to eventually catch.

  • OpenSSF Makes Free Security Training Available

    OpenSSF Makes Free Security Training Available

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is providing free security training for developers building and employing open source software starting later this week as part of an overall effort to advance best DevSecOps practices.

    Linux Foundation CTO Chris Aniszczyk said the Secure Software Development Fundamentals professional certificate program along with additional programs and technical initiatives soon will be required for every maintainer working on open source projects overseen by the Linux Foundation. As the number of applications that incorporate open source software has increased, the potential harm that can be inflicted by vulnerabilities introduced via code continues to increase, he noted.

    A larger percentage of those common vulnerabilities could be eliminated simply by providing developers with free access to training, Aniszczyk noted. Far too many developers and software engineers have not had access to security training beyond a few rudimentary courses in college, while many other developers are self-taught, he said.

    Accessed online via the edX learning platform, the courses are designed to teach developers and software engineers how to develop secure software while reducing the potential for damage and increasing the speed of the response when a vulnerability is found.

    The OpenSSF has also revealed existing projects from the Core Infrastructure Initiative (CII). The CII Census, quantitative analysis to identify critical open source projects, and CII FOSS Contributor Survey, a quantitative survey of developers, have become part of the OpenSSF Securing Critical Projects working group. These two efforts will continue to be implemented by the Laboratory for Innovation Science at Harvard (LISH). The CII Best Practices badge project is being transitioned into the OpenSSF.

    OpenSSF also announced new contributors, including Arduino, AuriStor, Canonical, Debricked, Facebook, Huawei Technologies, iExec Blockchain Tech, Laboratory for Innovation Science at Harvard (LISH), Open Source Technology Improvement Fund, Polyverse Corp., Renesas, Samsung, Spectral, SUSE, Tencent, Uber and WhiteSource.

    It has also elected an advisory council and governing board members with Kay Williams from Microsoft becoming Governing Board Chair. Other newly elected board members include Jeffrey Eric Altman from AuriStor Inc., Lech Sandecki from Canonical, Anand Pashupathy from Intel and Dan Lorenc from Google as the Technical Advisory Committee (TAC) representative.

    Ryan Haning from Microsoft has been elected Chair of the Technical Advisory Council (TAC) and an election for a Security Community Individual Representative to the Governing Board is currently underway. An OpenSSF Town Hall will be held online Nov. 9.

    Open source software obviously plays a critical role in boosting productivity because it means developers don’t have to constantly duplicate the same functions across multiple projects. However, if a vulnerability is discovered in one open source library the implications across multiple projects that have reused that same library can be profound. As part of an effort to ensure continued reliance on open source code, it’s incumbent on the open source community to make sure that code being shared is secure. In effect, responsibility for open source security needs to shift left at a massive level of scale. The challenge now is making sure that now open source developers have access to training the best DevSecOps practices that training enables are actually implemented.

  • How to Secure Fintech Applications and Protect Customer Data

    How to Secure Fintech Applications and Protect Customer Data

    All industries are feeling the pain of preventing rising risks to their applications, private information and customers’ data, and it is not surprising that this is especially true in the financial services sector. In fact, fintech companies on average spent more than $18 million in 2019 battling cybercrime, while other markets’ companies spend an average of $13 million addressing cybersecurity concerns each year.

    While these numbers can be depressing, a recent virtual roundtable we hosted with some of the best AppSec brains in fintech uncovered three steps organizations can take to secure their fintech applications and protect their customer data. The panel included Erick Lee, director of Security at Intuit; Jeremiah Kung, first vice president and global head of digital cybersecurity at East West Bank; and Karthik Rangarajan, security lead at Robinhood.

    The panel discussed AppSec trends, best practices for what is working in their organizations and recommendations for security leader peers who are tasked with addressing application security at their organizations. The group agreed that there’s a lot of creative thinking and exciting work happening around AppSec, and that includes across all of DevOps and engineering, not just those charged with application security. These notions can’t help but leave one feeling optimistic.

    While the spirited discussion covered a variety of topics and trends, here are the three high-level recommendations organizations should follow to best secure their fintech applications.

            1. Make sure AppSec teams are hiring software engineers. The panelists agreed that security and engineering functions should not operate as separate entities. One participant described why he hires software engineers instead of security engineers. He explained that software engineers know how to create fixes and operate at scale, which is critical for his organization, which manages 1.5 million requests per second. Since many organizations do not have the resources to hire a security engineer, particularly smaller and growing groups, it is especially important to build security into the engineering team.Organizations tend to discover scalable methods of solving problems and accelerating the development process when engineers are engaged with security. Take for example a security concern that delayed an application release. The panelists agreed that unless the issue is a show stopper, security should not delay a release, unless of course there is a compliance concern or potential violation. They recommended for developers do their thing, and let security work hard and try to keep up.

              The panelists explained this is because companies need to keep pace and release products and triage at scale. This is especially true in the fintech space, where winning business is about application features and capabilities. As an example, one panelist illustrated how his company’s focus is trying to ensure developers have paved roads so they can get “speed to benefit to customers.”

              To make this happen, his company deployed tools for automation, such as solutions that scan GitHub code for potential issues. They are also leveraging automation to monitor for security problems all through production. The punch line for them is to make security complementary and seamlessly woven into the workflow, it cannot be a secondary process slowing development.

           

          1. Compliance should be approached as an engineering problem. A significant challenge for financial services companies and fintech continues to be adhering to governance and compliance requirements. One of the reasons is a lack of automation and solutions that scale, which come at significant costs. In fact, one-third of global financial services companies spend more than 5% of their budget just on addressing compliance.Many financial services organizations rely on spreadsheets, PDFs, paper files and email chains to address and prove compliance. Fintech companies continue to address compliance questions using paper documentation and manual work. These methods are clearly not scalable and not sustainable for growing organizations to meet their expanding compliance demands.

            Fortunately, as the panelists uncovered, compliance and governance can be viewed through an engineering lens, as they have seen happen at some of the best fintech companies. One panelist illustrated that at his company he met with compliance experts to learn precisely about their problems, so his team could engineer solutions. After discovering the issues and metrics needed to prove compliance effectiveness, his team introduced automation and new tools to address the issues. His company knows the compliance methods are working if the metrics are being met, he said.

            Another panelist added that meeting regulatory compliance within a global organization like his introduces additional challenges of meeting compliance requirements in multiple jurisdictions. But the need to understand where data is and how it is being kept safe is common across the board. If you can address those questions, he said, then proving that the data is safe becomes the main task.

            For development and application security to remain sustainable, compliance cannot remain manual and human based. The panelists agreed that it’s unlikely to be able to fully automate all of the reporting and processes needed, but with a goal of 80% automation and 20% manual methods, organizations will be in a much better position.

          2. Security must be proactive. This is a common theme in our industry these days, and it certainly was popular thought the entire roundtable discussion. The panelists highlighted that fintech engineering teams are thinking about compliance and security in a variety of proactive ways. One panelist recalled that he asks his teams to “lean into security and do right by the customer before the company is asked to do so.”

      The areas addressed throughout the discussion ranged to a variety of topics, including how these days security is kept top of mind for engineering leaders during the hiring process. Participants agreed that hiring an AppSec developer is like finding a unicorn. The trick they said is to be more proactive and nurture your own unicorns internally. This can be accomplished by focusing on hiring top security developers and growing them into security roles. The result has significant benefits on all sides. The company will build its AppSec resources and expertise, and employees can value the opportunity to grow and expand their experiences into new areas they may not have known before.

      The panelists highlighted that exploring ways to ensure and accelerate approval for security features is a good way to ensure proactive security. One approach is to connect compliance issues that need addressing with security advancements. For example, if the goal to help prevent customer data loss is to add two-factor authentication, one should link a compliance issue that can also be solved by the requested security solution. Decision-makers may look to save budget and pass on simply adding security features, but it will be more difficult to say no to a compliance request. This kind of creative strategic thinking has a way of being a win-win for the company as well as its customers.

      The success of AppSec among financial services organizations depends on more than just effective security protocols that secure companies and protect customers. It needs creative, innovative and strategic ideas to enable organizations to have efficient, economical and scalable security. If that sounds like something your organization is seeking, then according to our roundtable panelists our industry has a very bright future.

  • DevOps’ Role in Fixing Software Vulnerabilities

    DevOps’ Role in Fixing Software Vulnerabilities

    From the beginning, application development has required that software developers deal with bugs, vulnerabilities and other issues. But problems encountered under the DevOps model tend to be more manageable since the updates and fixes required are usually smaller. The reason for this is that the process of maintaining and improving DevOps-related software never stops. In other words, problems that do need to be corrected are typically tackled faster under the DevOps model.

    In looking at the DevOps cultural shift that has fast-tracked the software development process while making security part of that process, it’s critical to consider how the DevOps process impacts software development, the issues around hackers taking advantage of vulnerabilities in code and why companies need to protect their infrastructure that incorporates speed and security.

    How DevOps Practices Impact Software Development

    DevOps practices impact every level of the software development process. In the past, software developers would churn out new app versions, sometimes every few years and sometimes every couple of months.

    This afforded developers sufficient time to go over their code with a proverbial fine-tooth comb. It also allowed them to devote more time to quality assurance efforts, which helped to minimize vulnerabilities that hackers could use to their own advantage.

    But the rise of DevOps has drastically revolutionized the way software is developed and delivered to customers. Instead of releasing new versions of apps perhaps yearly, software developers operating under the DevOps model can release updates and fixes quickly and on an ongoing basis.

    Facilitating the software development process over the course of the DevOps life cycle are tools such as Jenkins or Docker that allow the automation of many procedures and applicable processes.

    Quite simply, DevOps practices positively impact software development. The benefits can be broken down into three categories, namely technical, cultural and business, and as can be seen below:

    1. Technical Benefits: Ongoing software development, less complexity to take on and faster resolution of problems or issues.
    2. Cultural Benefits: Teams more fulfilled and productive, greater worker engagement and more professional development options.
    3. Business Benefits: Speedier delivery of features, more durable operating environments and better collaboration.

    It goes without saying that DevOps has a major and even revolutionary impact on the process that software development teams use to create applications as well as to fix vulnerabilities. It proves that doing things faster doesn’t have to mean proceeding in a haphazard manner.

    Issues Around Hackers Exploiting Code Loopholes

    Implementing the right processes and procedures can cut down on exploitable vulnerabilities. But software developers understand that hackers wake up each morning scheming up new ways to exploit code and infrastructure, which is why the struggle never stops. One of the issues customers are justifiably concerned about is privacy.

    The answer is to take DevOps to the next level. In other words, software developers need to adopt the DevSecOps model, which refers to implementing open source security procedures in the beginning stages of the software development life cycle. Open source security measures are essential for DevOps security teams because of the fact that they are lower cost, more innovative and allow teams to make the most of their continuous delivery processes. This includes, but is not limited to, code analysis, vulnerabilities assessments and compliance monitoring.

    When software teams purposefully and intentionally implement security practices within an Agile framework, they will be able to safeguard the integrity of their codebase. This can be accomplished with continuous evaluation, testing and updating.

    Why Businesses Need to Maintain Fast and Secure Infrastructures

    More companies are investing in protecting their infrastructure than they ever have before, as infrastructure protection spending this year could reach $17.5 billion worldwide, up from $12.6 billion in 2017. So while there is crystal clear evidence that more companies recognize the need to protect their infrastructure from nefarious actors, they are also, in fact, doing something about it.

    The consequences of failing to maintain a fast and secure infrastructure can be disastrous. Consider the following statistics that show some of the problems that can materialize: On average, it takes 206 days just to identify a data breach, and over 30% of companies encountered cyberattacks on operational technology infrastructure last year alone.

    So what can software development teams do to help organizations maintain secure infrastructures at a time where hackers are tirelessly persistent? While customers expect software to be delivered post-haste, they also expect it to be secure.

    Software developers need to commit to DevOps and DevSecOps to ensure that the software they develop and deliver to customers is free of exploitable vulnerabilities that could jeopardize their infrastructure, scare off their clients and even potentially wreck their operations altogether.

    Customers also have a role to play to keep their infrastructure safe. They should, for instance, have policies in place to govern how their workers use the software, roll out updates and fixes as soon as they are available, and use the right tools to protect their infrastructures.

    Conclusion

    By leveraging the DevOps model to make security part of the corporate culture and by training team members so that everyone adopts coding habits that are rooted in security, and by automating security in the development process, software development teams can deliver safe products quickly.

    At a time when customers expect deliverables fast, software development teams need DevOps so they can go from the development stage to the delivery stage without needless delay. The DevSecOps model is one in which security is purposefully implemented at each stage of the software development process, not simply a value-added component.

  • GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech Discovers Vulnerabilities in Third-Party Code

    GrammaTech today launched a CodeSentry software composition analysis (SCA) for binaries that inventories third-party code used in custom applications and identifies known vulnerabilities.

    Vince Arneja, chief product officer for GrammaTech, said the bulk of custom applications today are made up of binaries based on components developed by a third-party that comes in the form of open source, commercial-off-the-shelf (COTS) or existing custom software.

    CodeSentry detects these components and vulnerabilities associated with third-party code, including network components, graphical user interface (GUI) components or authentication layers. It uses deep binary analysis to create a detailed software bill of materials (SBOM) and a comprehensive list of known vulnerabilities.

    Arneja said that as responsibility for security continues to shift left toward developers, there is a need for tools such as CodeSentry that make it easier to identify vulnerability issues in binaries because many developers may not have access to the underlying source code used to construct the binary. CodeSentry identifies components present in native binaries using a range of matching algorithms to gather version number ranges, create an SBOM and provide links to CVE and CVSS scores, said Arneja.

    CodeSentry extends algorithms that GrammaTech developed to detect components in applications, including strings used in natural language processing. It maps components to multi-dimensional vectors and compares them to vectors derived from the components. The upload interface for the tool accepts native binaries, zip files and other archives. Once those files are loaded, CodeSentry analyzes the code that will run rather than the build environment to reduce the number of false positives that would be generated in build environments or components that are not actually being employed.

    GrammaTech next year intends to make CodeSentry available via a software-as-a-service (SaaS) platform, noted Arneja. GrammaTech ultimately envisions CodeSentry being employed as part of DevSecOps workflows driven by a continuous integration/continuous delivery (CI/CD) platform using a set of open application programming interfaces provided by the company, said Arneja.

    While there’s a lot of focus these days on melding DevOps and cybersecurity workflows as part of an effort to embrace best DevSecOps practices, the easiest vulnerability issue to resolve is the one that never existed in the first place. As developers gain access to cybersecurity tools, the number of vulnerabilities making it into applications should significantly be reduced in the months ahead. The challenge IT leaders face is making sure developers have access to those tools, which in turn will ultimately boost the confidence level cybersecurity teams have in application developers, who are often viewed as the primary cause of the problems cybersecurity teams are trying to resolve.

    Regardless of how IT organizations achieve that goal, the return on that investment is likely to be substantial. The amount of time and effort IT teams spend tracking down vulnerabilities that are much more expensive to fix after an application is deployed in a production environment is incalculable.