Tag: supply chain

  • How to Get the Supply Chain Back to (Better than) Normal

    How to Get the Supply Chain Back to (Better than) Normal

    If a chain is only as strong as its weakest link, today’s supply chain is in dire straits. A recent infographic from The New York Times shows all too clearly that the international supply chain is in upheaval, due directly or indirectly to the outbreak of COVID-19. At the same time, reams of data generated along the supply chain are going to waste. The internet of things (IoT) can’t single-handedly fix the supply chain, but IoT technology combined with the cloud, AI and automation has the potential to bring the supply chain (and society) back to something resembling normal—actually, something better than normal.

    Indeed, even during “normal” times, the supply chain was stretched to the limit by the challenge of constantly reducing costs and improving margins, as well as optimizing delivery times for just-in-time (JIT) inventory. With that said, the last two years have been especially grim, with factories, stores and restaurants literally shutting down for lack of materials. Then there’s the computer chip shortage, which is doing nothing less than “dragging down the economy,” according to a White House briefing room document,

    The problem is now multifaceted, so the solution is not going to be as simple as adding a better monitoring mechanism.

    At a minimum, companies need better visibility into and transparency of their supply chains. This gives them more control over the entire manufacturing process, from sourcing raw materials to delivery of final products. Technologies like IoT, AI/ML, automation and edge computing can optimize supply chain management by providing visibility and metrics so companies can make real-time decisions.

    In manufacturing, for example, IoT can bring greater visibility into the production workflow. Data from the digital twins of machinery—analyzed in real-time and fed back to control systems—can lead to improved levels of operational and business efficiency. When manufactured goods are ready to be shipped, IoT technology can guide the logistics and transportation of goods as they move from manufacturers to end users. In addition to managing supply, companies also need to get better at predicting customer demand so it’s a self-sustaining feedback loop.

    However, companies adopting these technologies need to be aware that they will not be effective on their own. As with any digital transformation initiative, people and processes are as important as technology. To ease or even overcome today’s supply chain challenges, companies must not only agree on common data exchange formats and APIs across the supply chain but also dedicate themselves to ongoing cooperation and motivation to achieve the common goal of streamlining and hardening the supply chain. To these ends, open source will be critical to the ongoing development of common, industry-wide standards that enable companies to future-proof their solutions.

    For example, carmakers such as Tesla are simplifying their supply chain by using a higher-end processor that can perform multiple functions rather than using dozens of dedicated microcontrollers for each function, with updates pushed out over the air. Organizations need to think along similar lines when it comes to their IoT architecture. Developers have historically thought about IoT applications in a discrete way—creating custom frameworks for creating apps for low-power devices. Rather, developers should be considering IoT applications as an extension of their application portfolio—using the same languages, frameworks and tools for IoT apps that they use for cloud applications.

    Post-Pandemic Supply Chain Issues

    As we move into the next phase of the pandemic, it might be tempting to believe that all will be right with the supply chain world. However, beyond COVID-19, there are several macro trends that will affect the supply chain, including climate change, cybersecurity and the changing dynamics of global trade.

    To combat climate change, for example, companies will need to reduce their Scope 3 emissions. The EPA defines Scope 3 emissions as the result of activities from assets not owned or controlled by companies themselves but by their supply chain (or value chain). Scope 3 emissions are often the majority of a company’s greenhouse gas emissions. To reach sustainability goals, companies will need better resource management of their supply chains.

    Supply chains also are increasingly being used as a cyberattack vector. This includes both physical entities, like building operations (such as the hack of Target systems via a third-party HVAC vendor) or the software supply chain (such as the SolarWinds hack). In fact, it’s no longer a matter of if an organization gets attacked, but when.

    The war on Ukraine has magnified the intricacies of our hyperconnected global economy. The U.S. government and its allies have imposed severe sanctions on Russia, a move that will have widespread repercussions. The New York Times reported that the “response that U.S. officials have promised could roil major economies, particularly those in Europe, and even threaten the stability of the global financial system.” The same could be said for the global supply chain, if Russia responds by, for example, cutting off shipments of materials needed to build semiconductors or mounting new cyberattacks.

    Conclusion

    COVID-19, a steady and stealthy rise in cyberattacks, trade barriers, war … None of these factors caused the problems we’re seeing with both physical and technological supply chains; rather, they have exposed existing weaknesses for all the world to see—and experience. Organizations must work together to increase resiliency and security through the use of key technologies such as IoT, AI/ML and edge, as well as a commitment to open, standards-based solutions.

  • Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian has added an extensible catalog for tracking software components, dubbed Compass, to its portfolio of DevOps tools along with an Atlassian Data Lake and Atlassian Analytics cloud service that makes it simpler to aggregate and query data collected from the company’s portfolio of tools.

    In addition, Atlassian is making its Atlas collaboration framework—formerly known as Team Central—formally available in beta. That framework, in effect, provides an overlay through which different collaboration tools adopted by various DevOps teams can be more easily integrated.

    Compass provides DevOps teams with the ability to map all the components they use to assemble their software as well as the teams that own them. DevOps teams can access shared components and documentation along with scorecards to allow them to measure and evaluate their architecture based on the baselines, security or compliance requirements they might be required to meet. It can be extended to other applications via an integrated Apps engine using Forge, the existing Atlassian cloud development environment.

    Tiffany To, head of product for Agile and DevOps at Atlassian, said Compass is designed for DevOps teams that are typically trying to manage 50 or more microservices. It is designed to be deployed alongside the Jira project management software that is widely used by software development teams to manage multiple projects.

    Atlassian Analytics, meanwhile, is based on a visualization and analytics platform the company gained last year with the acquisition of Chartio. Initially, the Atlassian Data Lake will include data from Jira Software and Jira Service Management tools with support for additional Atlassian platforms planned.

    Collectively, these tools are part of an ongoing Atlassian effort to make it simpler to integrate multiple DevOps teams, said To. Many of those teams prefer to maintain autonomy over the tools they select. The challenge that creates is organizations need some type of overlay through which they can collaborate and share best practices, she said.

    A survey of 2,000 developers conducted by Atlassian found half of the respondents exercise strong autonomy over the tools they use, with more control over tool selection gained as developers become more experienced. The same survey also found that 65% of developers felt they should be responsible for more of the software product life cycle than they currently are.

    It’s apparent that most organizations building software are trying to strike a balance between developer autonomy and centralized control. Developers are expensive to hire and retain, so there is a natural tendency to make available the tools they prefer. That, however, can lead to a level of tool sprawl that makes it difficult to determine the overall state of application development and deployment within an organization.

    Regardless of the approach, the need to remove as much friction as possible from DevOps workflows is clear, especially as the number of simultaneous application development projects continues to multiply. The challenge and the opportunity, of course, is achieving that goal while keeping developers happy.

  • Google Allies With GitHub to Secure Software Supply Chains

    Google Allies With GitHub to Secure Software Supply Chains

    Google today revealed it has been working with GitHub to create a forgery-proof method for signing source code as part of an ongoing effort to better secure software supply chains.

    Bob Callaway, technology lead for open source software supply chain security at Google, said a prototype of this method, written in the Go programming language, generates non-forgeable provenance using GitHub Actions workflows for isolation and code signing tools for authenticity provided by Sigstore. Projects that make use of GitHub runners to run jobs can now achieve the third level of security as defined by the supply chain levels for software artifacts (SLSA) framework to assure software artifacts are authentic and trustworthy, he said.

    The reusable workflow also protects against possible interference from maintainers who could otherwise try to define the workflow in a way that interferes with the builder. The only way to interact with a reusable workflow is through the input parameters it exposes to the calling workflow, which prevents maintainers from altering information via variables, steps, services and defaults.

    The goal is not only to ensure the provenance of individual software artifacts but also make it possible to identify which build system was employed to create that artifact, said Callaway. In addition to working with GitHub, Callaway added that Google expects to apply this method to securing other build systems that organizations used to construct applications.

    Overall, Callaway said, Google is also working toward embedding security functions with DevOps platforms to ensure the integrity of software supply chains, in addition to educating developers on how to build more secure software.

    To protect against the possibility of one job tampering with artifacts used by another job, Google’s method creates a trusted channel. Job outputs send hashes that are then used to verify the binary received via the untrusted artifact registry. The OpenID Connect (OIDC) protocol, which GitHub just opted to support, is then used to prove the identity of the workflow to an external service, such as Sigstore, by attaching a unique JSON web token (JWT) to each runner. The token contains verifiable information about workflow identity such as the caller repository, commit hash, trigger and the current workflow path and reference.

    That makes it possible for the workflow to prove its identity to the  Fulcio root certificate authority provided by Sigstore. Fulcio signs a short-lived certificate attesting to an ephemeral signing key generated in the runner. A record of that signing is kept in Sigstore’s transparency log Rekor. Users can then rely on the signing certificates to verify provenance in a way that is authenticated and non-forgeable. That approach means maintainers don’t need to manage or distribute cryptographic keys for signing, which until now have made it challenging to manage code signing at scale, Callaway noted.

    In the wake of a series of high-profile security breaches involving open source software, Google and others have significantly increased the resources being applied to securing both open source and proprietary software within the context of a set of DevSecOps best practices. It may be a while before the benefits of that effort are pervasively employed by developers, but it’s clear that substantial progress is being made involving everything from the tools developers use to the build systems managed by DevOps teams.

  • Linux Foundation Lists Top Open Source Libraries

    Linux Foundation Lists Top Open Source Libraries

    The Linux Foundation today published a report that provides access to eight lists of the top 500 open source libraries being used by organizations as part of an ongoing effort to help better secure software supply chains.

    The Census II of Free and Open Source Software—Application Libraries report is based on usage data from providers of software composition analysis (SCA) tools such as Snyk, the Synopsys Cybersecurity Research Center (CyRC) and FOSSA. The report itself was compiled by the Harvard Lab for Innovation Science.

    The eight lists are made up of four that include version numbers and four that are version agnostic. The lists are separated into npm and non-npm packages because npm packages would dominate any ranking created. The top non-npm packages being employed include maven, nugget, Go and cargo.

    Frank Nagle, assistant professor at Harvard Business School, said the report is intended to provide organizations with some guidance in terms of knowing what open source packages are used in the wake of recent vulnerabilities discovered in the widely employed Log4j software used to manage logs within Java applications.

    Many of the organizations impacted by that vulnerability were unaware of just how widely deployed Log4j was within their enterprise IT organizations. IT organizations should evaluate the sustainability of those projects in terms of the number of contributors and maintainers that are working to ensure the security of those libraries.

    One of the biggest challenges is to find a way to standardize naming schema for software components and the overall management of versions of different libraries, noted Nagle.

    Ultimately, the goal is to convince more enterprise IT organizations—and the vendors that support them—to make more resources available to secure those libraries, noted Nagle. Much of the most widely used open source software is developed and maintained by only a handful of contributors. Many of those contributors argue that, while they made that software available for free, it is the responsibility of the organizations employing it to secure it.

    The Linux Foundation is moving to become a conduit through which it will make available additional resources to help better secure open source software. The Open Source Security Foundation (OpenSSF), a consortium hosted at the Linux Foundation, earlier this week announced that 19 additional organizations have joined OpenSSF to help identify and fix security vulnerabilities in open source software and improve tooling, training, research, best practices and vulnerability disclosure practices.

    Brian Behlendorf, executive director at OpenSSF, said in addition to making resources available, it’s clear there is a need for some form of a third-party audit of open source software as organizations are more broadly employing that software across their software supply chains.

    New premier member commitments to OpenSSF are now coming from 1Password, Citi, Coinbase, Huawei Technologies, JFrog and Wipro. New general member commitments are being made by Accuknox, Alibaba Cloud, Block, Inc., Blockchain Technology Partners, Catena Cyber, Chainguard, DeployHub, Gravitational Inc., MongoDB, NCC Group, ReversingLabs, Spotify and Wingtecher Technology. New associate members include Institute of Software, the Chinese Academy of Science (ISCAS), MITRE and OpenUK.

    Other efforts led by the OpenSSF include an Alpha-Omega Project to better secure open source security posture, scorecards that identify risks of the dependencies within more than one million projects, multi-factor authentication tokens and a Project Sigstore initiative to sign, verify and protect open source code.

    It may be a while before open source software achieves the level of security the IT industry strives for. On the plus side, however, there have never been more resources allocated to achieving that goal.

  • Codenotary Launches Cloud Service to Generate SBOMs

    Codenotary Launches Cloud Service to Generate SBOMs

    Codenotary has launched a Codenotary Cloud platform that can automatically generate a software bill of materials (SBOM) and make it easier to discover what components have been included in an application.

    Moshe Bar, Codenotary CEO, said that capability can also play a key role in identifying which components in an application might contain, for example, the Log4jShell vulnerabilities that were recently discovered in Java applications.

    That capability can reduce the time required to remove insecure artifacts by as much as 80% simply because organizations are not dependent on scanning tools to search for vulnerable components, added Bar.

    Codenotary Cloud is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. In the wake of a series of high-profile breaches, there’s now a lot more focus on the integrity of software supply chains. In fact, the Biden administration recently issued an executive order requiring all federal agencies to, among other things, make sure an SBOM is available for all the software they use.

    Codenotary claimed Codenotary Cloud can scale to millions of integrity verifications per second across source code, builds, repositories, Docker container images and Kubernetes deployments in a way that doesn’t require DevOps teams to upload data to a centralized platform, noted Bar. That makes it possible to notarize and verify the provenance of all the code being employed, he added.

    Codenotary Cloud can also be fully integrated with most vulnerability scanners and popular cloud-native continuous integration/continuous delivery (CI/CD) systems running on any cloud or on-premises host via a managed service. Pricing starts at $5,500 for a workgroup of 10 developers.

    It’s not clear to what degree the Biden administration’s executive order will improve overall software security. There have been multiple vulnerability issues over the years that have not resulted in any material change in how organizations manage their application development processes. However, the executive order issued by the Biden administration, coupled with a recent summit on the state of open source software security, means more senior business and IT executives are at least aware of growing concerns.

    The one thing that is certain is there will be more zero-day vulnerabilities discovered. Developers today routinely reuse open source software and free components maintained by a small number of volunteer programmers. Like any other developer, the amount of security expertise those individuals have is limited. Many organizations reuse that code without contributing anything meaningful back to the project—either in terms of financing or vulnerability identification and remediation support. Contributors to these projects freely donate their time and expertise to build these components. Many of those contributors feel the onus for securing the software they created is on the organizations that decide to deploy that software.

    Regardless of who is responsible for security, it’s apparent cybersecurity teams are going to be reviewing application development processes. Theoretically, that should benefit all concerned and lead to DevSecOps best practices being more widely adopted.

  • Using Open Source to Secure Software Supply Chains

    Using Open Source to Secure Software Supply Chains

    Recently, there’s been a lot of attention paid to software supply chain security. In particular, here’s a quote from the May 2021 presidential executive order on improving the nation’s cybersecurity: “The Federal government must … advance toward zero trust architecture; accelerate movement to secure cloud services, including … platform as a service (PaaS).”

    There are two parts necessary to create a truly trusted software supply chain; securing the non-technical areas and securing the technical areas.

    Non-technical aspects of any secure software supply chain involve having individuals or teams focused on security and audit compliance. Internal company policies that act as a regulatory system and set standards for developers are a must, as are efforts to enforce compliance with security best practices. While this can bode well for large organizations, small software engineering teams and startups do not have the bandwidth, budget or culture to make this a reality.

    Envisioning Robust Security Best Practices

    Tools that are open source, governed strictly and enable automation of secure build and deployment are the components that form the technical aspects of the solution. Engineering teams must find a way to envision robust security best practices and find a way to apply them without unduly affecting the developer workflow. This is a founding principle of the DevSecOps efforts within the larger community of software development professionals.

    Ergo, advocating a technology stack that:

    • Is composed of open components
    • Provides automated builds
    • Reduces the dependency on developers
    • Allows security operators to extend control
    • and is actively supported by the community is an ideal choice upon which to build a platform for use by development teams.

    The focus of this article is to describe a robust stack that will sit above compute resources and power applications. The stack will consist of fully customizable open source components that put reliability and security at the forefront.

    Simplify Operations

    Application source code is the single source of truth when working with this stack. The use of Git, a popular version control system that is free and open source will allow developers to work with a source code management system from which all the downstream steps will be triggered.

    Kubernetes is an open source container orchestration tool developed under the auspices of the Cloud Native Computing Foundation (CNCF). It serves as an abstraction over the infrastructure and compute layers to power the system from underneath. Kubernetes has managed to gather a large community following—second only to the Linux OS itself. Using Kubernetes will bring homogeneity above the infrastructure layer and will simplify further operations.

    Cloud Foundry is an open-source PaaS tool. The use of Kubernetes introduces complexity that introduces a bit of overhead for developers who work with the platform. Cloud Foundry provides a countermeasure that simplifies the developer experience and greatly eases the pain points commonly associated with Kubernetes adoption. The Cloud Foundry platform does the job of deploying all the applications to the Kubernetes infrastructure. The cf push command triggers the export of a container image from the application source code.

    When building these containers to deploy to the runtime within Kubernetes, Cloud Foundry uses Paketo buildpacks internally. Paketo buildpacks are an implementation of the cloud-native buildpacks specification which aims to provide a unified means to generate OCI-compatible container images for all languages and frameworks that are commonly used to build applications. Paketo buildpacks are also open source and fully customizable according to the needs of software development teams.

    A Trusted Architecture

    Together, this platform, built on open tools, supported actively by the community and facilitating the exact needs of software developers helps promote a trusted architecture upon which to stage applications. Using these tools would enable an organization to build a software development ecosystem that satisfies all the requirements implied and enumerated in the various recommendations for improving software security.

  • Log4j: It’s All About the Supply Chain, Baby!

    Log4j: It’s All About the Supply Chain, Baby!

    In 2021, the security story in DevOps and DevSecOps has been the supply chain. So, it’s only fitting that we are currently experiencing the mother of all supply chain issues with the Log4j Log4Shell RCE vulnerability to close out the year.

    I won’t waste your time rehashing what Log4j is, why it’s so dangerous and warning you to test all of your own and third-party apps to make sure you’re insulated against this. I will say, though, that I don’t think Log4j is a bug—I think it is a defect in design. Worse, as we are seeing, there are multiple defects in design. All of you Java haters out there—back in the box. Java is no worse or better than any other language that we regularly use to build applications.

    So, what exactly is so special about supply chain security? Why do DevSecOps teams, developers and our security incident management teams have to interpret this as a warning and stay at the top of their game from now on? It’s simple. In the age of SaaSOps; in a world where we Frankenstein applications by cobbling and stitching together numerous third-party components (some open source, some not), we are increasingly reliant on code, even in our own applications, that we did not write. We probably didn’t test it, either. We rely more than ever on the “community” and on unknown third-party suppliers. It has always been a leap of faith with these apps and components, and this year some of those chickens have come home to roost.

    The White House executive order on improving the nation’s cybersecurity calls for a software bill of materials (SBOM) for applications; that is, as they say at the tables in Las Vegas, a fine start, but we need more. If we really had a BOM included with the apps we use (and that includes SaaS apps), how many of you are actually going to read it and act on that information? And besides including all these components in a BOM, what further obligations do suppliers have to ensure that they are replacing and updating vulnerable code?

    This issue becomes increasingly acute with open source. My partner and colleague Mitchell Ashley recently asked if too much open source was a bad thing. I don’t know if I would go that far; the more the better, as far as I am concerned. But we do need better monitoring and management of the open source code that’s out there. More testing before it goes GA, maybe? Yeah, the Cadillac open source projects might have the money and time to do that, maybe, but take Log4j as a perfect example: It’s two guys maintaining it in their free time and trying to do right by the community. How can they possibly keep up?

    I used to think that the answer was in the repos. My friends at Sonatype had a component firewall that would not let you download an old or vulnerable version of code without warning. That was fine if you were downloading it for the first time. But if it was already embedded—then what? Can we scan for older components in an app? My friends at JFrog can do something similar and more with Xray. And Sonatype’s Nexus platform also allows current and prospective users to scan older apps for vulnerabilities—including scanning for Log4j, absolutely free. But is that enough?

    All of these questions involve open source components. What about third-party SaaS apps? Often, we don’t even know what components or code are in those SaaS apps. Again, it is a leap of faith we are making when using them. 

    These supply chain security issues are a problem that we are just beginning to grasp. And while 2021 has been the year the stuff hit the fan and Log4j may be remembered as the biggest of the first, I, for one, am afraid to think about what else is coming. 

    I do know that the only way to tackle this and any future supply chain issues is if developers, DevSecOps, DevOps, SREs and our security incident response teams all work together. Just like most security issues, supply chain security is all of our responsibility.  I hope Log4j hasn’t bitten you too hard, and that you are on top of your exposure. But let’s start thinking about the next one and how we can better prepare for it.

  • Codenotary Uses Immutable Database to Verify Software Artifacts

    Codenotary Uses Immutable Database to Verify Software Artifacts

    Codenotary today unfurled a free notarization and verification service for open source artifacts and containers to enable IT organizations to track the provenance of the components that make up their applications.

    Dennis Zimmer, Codenotary CTO, said the Community Attestation Service is based on an immutable open source immudb database that cryptographically attaches an identity to each software artifact. Additionally, the Community Attestation Service can be integrated with the continuous integration/continuous delivery (CI/CD) platform that DevOps teams employ to build and deploy applications using those artifacts, added Zimmer.

    The identities created by the Community Attestation Service can then be used to verify a software bill of materials (SBOM) that will soon be required by not only every U.S. federal agency but also organizations that are trying to better secure their software supply chains in the wake of a series of high-profile breaches, said Zimmer. The Community Attestation Service will also encourage developers to reuse source code, builds, repositories and Docker container images that they know they can reliably employ within a zero-trust IT environment, noted Zimmer.

    Some developers have, of course, been signing their code for years, while others simply didn’t see the need. With its free service, Codenotary is trying to expand the pool of developers that will not only sign their code but do so in a way that can’t be tampered with later, noted Zimmer.

    Unlike blockchain databases that are employed to provide immutable records of transactions, Zimmer said the immudb platform was created to provide an immutable database capable of processing millions of transactions per second. That database is also being used to build a wide range of applications that go beyond the scope of the Community Attestation Service so DevOps teams can have confidence in the viability of the underlying platform, noted Zimmer.

    In the wake of some troubling security breaches, it’s now only a matter of time before security teams start to ask more difficult questions about how applications are built. Developers could wait for those cybersecurity teams to eventually create policies that DevOps teams would be required to enforce, or they can more proactively embrace a service that tracks the provenance of code that hopefully, has been scanned for all known vulnerabilities. In fact, it may not be too long before organizations decide not to employ code that has not been verified. There may even be a backlash against using code that is unsigned that could result in many existing applications either being updated or outright replaced.

    On the plus side, Zimmer noted there’s a lot more awareness of the need to sign code. The challenge is most organizations don’t have the processes in place. Fortunately, there’s a lot more interest in DevSecOps best practices to ensure the integrity of code. However, awareness of the need for something doesn’t always result in concrete actions being taken unless DevOps teams can simply make it easy for developers to do the right thing. After all, it’s not as though developers want to employ insecure code, it’s just that they are often simply too busy to make sure every last artifact employed is verified as secure.

  • Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype Report Shows Spike in Supply Chain Attacks

    Sonatype today released a report that finds there has been a 650% year-over-year increase in supply chain attacks aimed at upstream public repositories. Cybercriminals hope to compromise these repositories by injecting malware into software components that many organizations might be using, according to the report.

    The seventh annual State of the Software Supply Chain Report is based on an analysis of 100,000 applications and 4 million component migrations made in the last month alongside a survey of 702 software engineering professionals. Specifically, the report focuses on demand and security trends associated with the Java (Maven Central), JavaScript (npmjs), Python (PyPI) and .Net (nuget) ecosystems. The top four open source ecosystems now contain a combined 37,451,682 different versions of components, a nearly 20% increase year-over-year.

    Over the course of 2021, developers also downloaded more than 2.2 trillion open source packages from the top four ecosystems, a 73% increase over the prior year.

    However, despite the huge available supply of open source software, use of this software is primarily concentrated in a small number of popular projects. Production applications are only using 6% of available open source projects.

    Not surprisingly, popular projects are more vulnerable to compromise. A total of 29% of popular project versions contain at least one known security vulnerability. Conversely, only 6.5% of projects that are not widely used have vulnerabilities.

    Stephen Magill, vice president of product innovation for Sonatype, said popular open source projects tend to have better security practices in place because of the larger number of maintainers and contributors working on the project. The paradox is that less-popular open source software is not likely to be targeted by cybercriminals who tend to focus on targets that represent the best chance to infect downstream applications, said Magill. Popular open source projects were 2.8 times more likely to contain vulnerabilities, the report found.

    Projects with a faster mean-time-to-update (MTTU) are also generally more secure. They are 1.8 times less likely to have vulnerabilities, the survey found.

    The report also found developers make suboptimal choices 69% of the time when updating third-party dependencies, even when newer versions of projects are generally available. Developers may be avoiding those updates because they may be perceived to be not as stable as they would like. However, those updates generally contain the latest security patches needed to address a recently discovered vulnerability. Commercial engineering teams only manage 25% of the components they use, leaving the majority of their open source dependencies stale and susceptible to increased security risks, the report found.

    Finally, the report suggested there is a greater need for automation. Equipped with intelligent automation, a medium-sized enterprise with 20 application development teams would save a total of 160 developer days a year. Sonatype estimated that could save organizations $192,000 a year.

    In general, Magill noted that the security of software supply chains should continue to improve in the wake of an executive order issued by President Biden. In the meantime, however, most organizations would be well-advised to start reviewing the components and dependencies that make up their software supply chain sooner rather than later. After all, chances are good that cybercriminals are already doing much the same thing.

  • Sophos Acquires Refactr to Advance DevSecOps

    Sophos Acquires Refactr to Advance DevSecOps

    Sophos this week revealed it has acquired Refactr, a provider of an automation platform that makes it simpler to add static and dynamic security scanning and application testing to a DevOps pipeline. Terms of the deal were not disclosed.

    Joe Levy, Sophos CTO, said Sophos will extend the Refactr DevSecOps automation platform to add security orchestration automation and response (SOAR) capabilities. This will provide DevOps teams with access to its managed threat response (MTR) and extended detection and response (XDR) platforms. The goal is to make it simpler for DevOps and cybersecurity teams to collaborate once those integrations are achieved in early 2022, added Levy. Sophos will also continue to develop the Refactr platform as a standalone offering in addition to maintaining the current community edition of the platform, noted Levy.

    Refactr Sophos

    Sophos has acquired a range of cybersecurity companies since it rearchitected its core platform to create an extensible security framework known as the Adaptive Cybersecurity Ecosystem. That platform is built on a modern microservices-based architecture that simplifies integration of acquisitions. Collectively, those acquisitions enable Sophos to collect a wider range of data that can be used to train artificial intelligence (AI) models and continuously better automate DevSecOps processes, noted Levy.

    Recent Sophos acquisitions include Capsule8, a provider of a platform for securing containers and BrainTrace, a provider of managed security services. Sophos also acquired Rook Security, another managed security services provider, in 2019.

    In general, Sophos is making the case for a security platform that both DevOps and cybersecurity teams can navigate. In addition to integrating with continuous delivery and continuous deployment (CI/CD) workflows via application programming interfaces (APIs), the Refactr platform can also be accessed via visual tools that can be employed to create launch tests using a drag-and-drop tool.

    In the wake of a spate of high-profile software supply chain breaches, there’s now more focus on implementing DevSecOps best practices. The challenge organizations face is finding a way to achieve that goal without unduly slowing down the rate at which applications are built and deployed. Achieving that goal requires finding more ways to automate, for example, scans of code during the build process.

    In the meantime, however, a recent Sophos Active Adversary Playbook 2021 illustrates how organizations find themselves outgunned by their cybercriminal adversaries. The report details how 37 different attack groups used more than 400 different tools between them to launch cyberattacks. The attackers’ median dwell time before the attacks were detected was 11 days.

    It’s clear that without advances in automation and AI, the odds of securing software supply chains are slim to none. The challenge organizations face is finding a way to affordably tap into AI and automation technology and expertise. Individual organizations are not really in a position to build, for example, AI models capable of automating a cybersecurity process. Most organizations will wind up using APIs to invoke advanced security services delivered via the cloud within the context of a DevSecOps workflow. The issue is determining which service provider offers the most integrated and robust capabilities at the lowest cost.