devopsy.kinsta.cloud

Tag: devsecops

  • Securely Streamline Code Signing for DevOps and DevSecOps

    Securely Streamline Code Signing for DevOps and DevSecOps

    Introducing code-signing provides security within the application, but teams should take care to understand and implement the process effectively

    Digital certificate management, with hundreds or thousands of certificates required to support IT infrastructure, can easily lead to degradation of application integrity and unnecessary risk to the business. The cumbersome nature of siloed teams manually managing digital certificates often results in the bypassing of PKI standards mandated by their organization.

    Based on the complexity of their pipeline, DevOps and DevSecOps teams may issue certificates signed by an untrusted source and stored insecurely to speed up the build and deployment stages of CI/CD workflows to avoid a lengthy certificate request process, which could take weeks or even months. Using this manual, insecure cryptographic practice to sign and deploy code exposes organizations to a high level of avoidable risk.

    Code signing, and the certificates used in that process, should be centralized and automated using cryptographic hardware. Here we will walk through the process of hardened code signing and how to streamline its management in DevOps and DevSecOps pipelines.

    Hardened Code Signing in 4 Steps

    1. Unsigned code ready for distribution. Time to generate public-private key pair

    We start with an unsigned executable that is ready for distribution. To securely sign the code, the code publisher needs to generate a public-private key pair. This is required by most runtime architectures, including Windows, Java and others. The most secure way to generate code-signing keys is by using a FIPS 140-2 Level 3 validated hardware security module (HSM).

    1. Submit public key and Certificate Signing Request (CSR) to an issuing certificate authority (CA)

    With the key pair generated in step No. 1, the CSR is generated and submitted to an issuing CA. The CSR contains information that identifies the publisher and signature algorithm, as well as the digital signature. This information is used by the issuing CA to issue the code signing certificate.

    In some situations, such as with internet of things (IoT) device manufacturing, the organization may decide to act as its own Issuing CA.

    1. Identification of publisher and authentication of CSR

    The Issuing CA verifies the code publisher’s identity then authenticates the CSR, ensuring the publisher has digitally signed it. If both identification and authentication are successful, the Issuing CA packages the publisher’s identity with the public key then signs the package, creating the code-signing certificate.

    1. Ready to sign. Determine the level of security

    Now that the code-signing certificate is ready for use, any executable can be signed and deployed unless further code testing or QA needs to occur. Enterprises, particularly fast-moving ones, often find themselves storing their code-signing keys on the code publisher’s local machine or server, an insecure method that can result in significant problems. Storing the keys on a local machine or server presents major security risks. The local machine could become compromised/stolen along with the code-signing keys, or a disgruntled employee could maliciously sign and deploy unauthorized code, which could go unnoticed for a while.

    It is best to import and store the code-signing certificate in a key management server (KMS), which stores the certificate behind a FIPS 140-2 Level tamper-resistant physical boundary. In addition to hardened storage, a KMS with proper cryptographic features and functionality can be utilized to help automate the entire code-signing and certificate management life cycle. A KMS allows DevOps and DevSecOps teams to seamlessly meet best practices while removing the manual workflow bottlenecks and natively integrating with CI/CD systems. Less time generating and managing digital certificates results in faster code deployments and an increase in team output.

    Streamline Continuous Integration

    There is tremendous value in using an HSM for secure key generation and certificate storage. Additionally, DevOps and DevSecOps teams can drastically reduce the manual labor required with continuous integration code builds. For builds requiring a defined and trackable workflow for signing, code signing with CI/CD integration can offer significant benefits.

    This workflow typically consists of a CI/CD system that is managing the build and signing request process, a centralized and secure key management server to manage all code-signing keys and perform the signing process, and an approval entity to govern the process by which code is signed in an authorized manner.

    When deploying a system like this, backed by a FIPS 140-2 Level 3-validated HSM, organizations can also introduce automation into the process. This means that instead of code signing being a manually driven step that introduces room for human error, it is natively incorporated in the code development and release workflow.

    Integration With Code-Signing Technologies

    KMS and HSM cryptographic devices that provide hardened key storage commonly integrate with popular code-signing technologies that conduct various tasks such as validating publisher identity and ensuring code integrity. For instance, organizations using SignTool.exe with Microsoft Authenticode can directly integrate with a KMS with full certificate management functionality. Other integrations and use cases include Java Jar Signer, RPM (Red Hat), Docker, and various IoT implementations. Beyond that, innovative organizations are looking at systems that can deploy more advanced code-signing workflows outside of the standard OS and runtime SDKs, to integrate more tightly with CI/CD systems.

    Integrating HSMs into DevOps and DevSecOps pipelines simultaneously improves workflow efficiency and supports other cryptographic operations across the organization.

  • KubeCon Coverage: Incentivizing the DevSecOps Culture

    KubeCon Coverage: Incentivizing the DevSecOps Culture

    Just as DevOps set to de-silo development and operations teams, the DevSecOps movement is bringing security to the same table. A shift-left security mindset is permeating much discussion of late.

    Cyberattacks are on the rise in the era of COVID-19 and cybersecurity has become paramount to arm business-critical applications. Furthermore, new regulations have emerged to protect personally identifiable information (PII). A new cybersecurity awareness feels quite apparent throughout the tech spectrum. As a result, security policies are poised to integrate more directly within the process of engineering and deploying applications.

    Nonetheless, while DevSecOps feels necessary to implement at this critical hour, it does present challenges. Primarily of which is a significant cultural shift. Uniting security and development isn’t as easy as it sounds, especially when faced with rigid enterprise bureaucracy. Plus, how can an organization incentivize DevSecOps if developers fear security tools will slow down their workflows?

    The DevSecOps panel at the recent KubeCon + CloudNativeCon North America 2020 brought together leaders in the DevSecOps arena to advise introducing a security-first mindset to DevOps. Dan Papandrea, field chief technologist at Sysdig, led this super-informative panel. It featured:

    • Emily Fox, DevOps Security Lead, NSA
    • Peter Bosch, Cisco
    • Sunil James, HPE
    • Christian Weichel, Gitpod
    • Nicolas Chaillan, U.S. Air Force

    Below, I’ll cover some of the key insights garnered from the event. To summarize, the panel identified how policy-first tools and open source initiatives are placing security controls within IDEs and CI/CD pipelines. And what will it take to get everyone onboard? It appears that transparent tooling automation, making security adherence natural and a new wave of security-aware employees will be critical components in the future era of DevSecOps.

    What is DevSecOps?

    First off, to get a better picture, what exactly is DevSecOps? And why has it come about?

    In a previous article, we defined DevSecOps with six traits: security automation, security culture, de-siloing IT, shifting security left and security as an enabler (not a stalling force).

    The KubeCon panelists seemed to echo all of these points. Fox described DevSecOps as “a term used by organizations to ensure their DevOps approaches have a security-first mentality.” To her, this means placing security automation within workload environments.

    DevSecOps is something new. For most organizations, security isn’t baked into the standard development processes—it historically hasn’t been the first priority, Chaillan said. DevSecOps is changing that, adding continuous monitoring, zero trust enforcement and reducing the overall attack surface.

    The move toward continuous release is also an impetus for DevSecOps. “Our cadence of delivery has been quickened,” said James. All organizations now feel pressure to deliver value to customers rapidly. An interesting byproduct of building security-first, he said, is “the ability to create the consistency and speed with which you can actually offer these capabilities.”

    Another cause for DevSecOps is the sheer imbalance in the workforce. On average, the number of developers far outweigh the number of security folks, noted Bosch. So, DevSecOps could scale security across an organization more effectively than human power could.

    Bosch also is hopeful DevSecOps could put an end to time-consuming bureaucracies stalling an agile security process. “Developers used to write code and wait for free months to open a firewall.” This may have been standard operating procedure decades ago, but in the age of continuous everything, enterprises must evolve how they handle IT security policies. “By uniting security with developers, we bring speed, robustness, avoid OWASP issues, and build applications that better contribute to the bottom line,” he said.

    Finally, embracing DevSecOps is a significant commitment. The combination of culture and technology is essential, noted Weichel. As we infuse security testing into CI/CD pipelines and make everything security-first, he said, we indeed undergo a cultural shift—it’s something that permeates everything.

    Challenges in Implementation

    Companies attempting to introduce DevSecOps may run into a few challenges, including instilling the culture, implementing regulatory compliance and finding the right blend of open source and propriety tools to get the job done.

    Bosh is no stranger to sluggish enterprises and the systemic change required to introduce DevSecOps. In these environments, changing companywide antiquated processes may require executive sponsorship. “By and large, it’s mostly culture,” he said, yet acknowledged a vast divide between the two groups: “How do you convince security do get out of their comfort zone? And how do you convince developers to get out of theirs?”

    There is also developer experience to consider: Developers often view security tools as limiting their ability to deliver code quickly. Perhaps the biggest challenge to overcome is improving the experience of working alongside new security policies. If new practices are causing more pain, instead of automating pain points away, DevSecOps could suffer.

    Outside of team dynamics, there are also technical hurdles involved when introducing and enforcing legal regulatory requirements. “Getting any sort of compliance baked into CI/CD pipelines is a challenge,” said Fox. Part of the problem is that the tooling to enforce such requirements isn’t there yet. “Cloud-native is continually evolving and security is constantly playing catch up,” she noted. “It’s an ongoing challenge.”

    Incentivizing the DevSecOps Culture

    Employees need incentives to change established habits. With the above challenges in mind, how can organizations create incentives to adopt DevSecOps? Well, outside of monetary incentives or straight up demanding it, incentivizing that security culture could happen in a few different ways, the panelists noted.

    To Fox, it’s about “making security transparent to the developers.” You want developers to quickly build and deploy secure applications without the need for intensive cybersecurity training. Thus, the tools and processes must be as transparent and usable as possible. DevSecOps is possible “if you make it second nature,” she said.

    Another way to consider DevSecOps culture is the end performance. If customers are happy, this is a positive gauge. James said he has witnessed CIOs at a few organizations using customer satisfaction scores as a guiding light for not only the business but for security effectiveness well.

    Bosch similarly stressed an indirect incentive about overall company performance. “Companies that really embrace DevSecOps leads to better code,” said Bosch. This leads to more robustness, higher speed, and better-operating enterprises. Co-building a thriving success could be ample incentive alone for those who have the whole team in mind.

  • Gravitational Becomes Teleport to Streamline Access Management

    Gravitational Becomes Teleport to Streamline Access Management

    Gravitational today announced it has changed its name to Teleport and launched the Teleport Unified Access Plane, an open source security gateway that comes in the form of a single binary that acts as a proxy for remotely accessing Linux servers and Kubernetes clusters.

    Teleport Unified Access Plane (UAP) for managing those gateways can be either deployed by an IT team or accessed via a cloud service managed by Teleport.

    Offerings included in Teleport UAP are Teleport Server Access, Teleport Kubernetes Access and Teleport Application Access, which combined enable IT organizations to lock down access to an IT environment.

    Company CEO Ev Kontsevoy said Teleport UAP gives engineers via a single login access to just the IT resources they have permission to access. That approach reduces the myriad credentials that IT organizations currently need to manage across multiple networks.

    Teleport automatically discovers all the resources in an IT environment along with the protocols needed to access them. It provides a unified audit log in a JSON format that enables IT teams to track what resources are being accessed when and by whom.

    Access control is becoming a bigger issue because the overall IT environment is becoming more complex as the infrastructure stack required to run applications grows. Teleport provides a way to streamline access management across servers, clusters and databases.

    That issue is also becoming a bigger challenge with IT personnel now working from home to help combat the spread of the COVID-19 pandemic, added Kontsevoy.

    That fine-grained approach to access will ultimately eliminate the need to rely on virtual private networks (VPNs) at a time when the network perimeter continues to dissolve. In effect, Teleport enables IT teams to move toward a more identity-centric approach to unifying the management of access, he said.

    In general, he noted, Teleport enables organizations to manage security as code rather than having to rely on separate overlays. As such, they can shift responsibility further left toward DevOps teams.

    It may take some time for IT teams to aggregate all the access control protocols they currently employ under a single proxy. However, Kontevoy said, the massive amount of time and effort spent managing access control today will drive organizations that have embraced best DevOps practices to look for ways to automate what today is a very manual process.

    The challenge, of course, is finding the time to achieve that goal. Teleport is betting a single binary in combination with a control plane accessed primarily as a managed service will make it too simple for DevOps teams to ignore. Regardless of approach, however, it’s clear there needs to be a better way to manage access within the sea of servers, databases and applications that now make up the typical IT environment.

  • 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.