devopsy.kinsta.cloud

Tag: Software Supply Chain

  • GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian: 10M Exposed Secrets on GitHub

    GitGuardian published an analysis of more than one billion commits to GitHub repositories that found 10 million occurrences of secrets, with one out of 10 developers exposing a secret.

    Mackenzie Jackson, a developer advocate for GitGuardian, said more than 80% of all the secrets caught by live monitoring GitHub were exposed through personal repositories, with a large share of them being corporate secrets. In fact, three million of the secrets discovered were unique instances, with 5.5 commits out of every 1,000 made exposing a secret.

    On a year-over-year basis, the report also found that the number of hard-coded secrets discovered in these repositories increased 67%. More than half the secrets discovered (56%) contained a generic password.

    There appeared to be no correlation between developer experience and the number of secrets exposed. Junior and senior developers are equally predisposed to making the same mistakes, said Jackson. The most common mistake is secrets left exposed because developers used them to simplify access to components and resources when building their applications and then forgot to remove them when the application was deployed in a production environment.

    Secrets management is, of course, getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. The issue with secrets management is cybersecurity teams are usually a lot more focused on discovering vulnerabilities than looking for instances of poorly secured credentials. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all. In fact, the number of existing applications running in production environments that have issues with how secrets are managed could be staggering.

    In theory, at least, the adoption of DevSecOps best practices should be mitigating this issue, but as the volume of code stored in repositories continues to increase, it would appear more fundamental mistakes are being made. Cybercriminals, meanwhile, have a greater appreciation today for weaknesses in software supply chains, so many of them are scanning repositories for secrets that will enable them to breach an application.

    Of course, there’s a lot more attention being paid to secure software supply chains, especially in the wake of the Biden administration creating a National Cybersecurity Strategy that requires Federal agencies to, among other things, lock down software development life cycles on an end-to-end basis. Most enterprise IT organizations, if they have not done so already, are expected to follow suit.

    As a result, DevOps teams should expect to see more cybersecurity professionals focusing more on secrets management. Developers, naturally, will not want to be called out for mismanaging secrets, so over time, the overall state of application security should steadily improve. The issue, of course, is the volume of attacks against software supply chains is expected to increase. Many previous mistakes are likely to come back and haunt developers and the organizations that rely on their code and wreak havoc downstream.

  • Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Dev of core-js Will Flip Table ¦ Another 451 PyPI Maldeps

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Denis Pushkarev is fed up with core-js freeloaders, and hundreds more malicious packages found at PyPI. (more…)

  • Taking the Modular Route

    Taking the Modular Route

    In today’s world of continuous software development and integration, removing bottlenecks and increasing efficiency is of utmost importance. One surefire way to improve this efficiency is leaning into modularity–or ‘taking the modular route.’ In software engineering, modularity refers to building complex products or processes using individually distinct functional modules.

    An analogous way to describe this is thinking of modularity like you would Lego. Every Lego can connect to every other Lego using the same approach. But the way you put them together differs, from simple constructions to magnificent architectural creations, even though they’re made using components that connect in the same exact way.

    Put simply, modularity is a deployment strategy that allows for quick configuration changes through standardized methods. In that sense, software development is much more manageable when it is modular.

    A Way to Address Growing Complexity

    Modularity has been key in helping to build complex business solutions. Before developers started using this approach, the risk of a single update or software release taking down the program was very high–and common. Fortunately, modules became popular and combatted that issue with their parallelity, allowing multiple teams to work independently without affecting each other’s work.

    This cut down on the inevitable complexities that would emerge from the common issue of too many cooks (developers) in the kitchen (working on an application). And this applies all the way up the ladder to business leaders as well, who are able to now choose from various modules and plug the module into their ecosystem according to their specific requirements.

    The feature-independent modules can be regularly updated and tweaked without affecting other parts of the ecosystem. This way of continuous development looks seamless to the end user without any downtime. And developers often employ prewritten modules, which conserves resources and makes modularity successful.

    Promoting Innovation

    Developing modules individually greatly increases the rate of invention. Each department or business could delve further into its operations by focusing on a specific module. Having many teams focus on the design of a given module fostered numerous parallel solutions. Modularity, in this way, helps innovation happen more quickly within organizations–teams are given the ability to expand to a marketplace model where third-party developers can create their custom modules that are easily integrated.

    If you want to see a perfect example of modularity’s positive impact on innovation, take a look at how quickly the mobile app marketplace has grown. Thanks to modularity, third-party developers created their own modules based on set standards, which gave way to innovation and the mobile app marketplace. External developers can develop custom modules and plug them into a separate system.

    Take a look at your phone and it’s evident in Apple’s App Store. It has thousands of apps–the majority of which are from external developers. If an ecosystem supports modularity, custom module development is made available to partners and clients, which not only expands the product scope but also helps to fast-track the launch of new products.

    Standardization and Scaling Up

    Modularity’s standardized function is a crucial advantage for developers. The same modules can be used across different businesses, which reduces the need to design custom solutions. During the development phase, which is fast-paced and demanding, this standardization improves product quality while reducing errors and oversights.

    The business flows are designed with the same plug-and-play approach–giving the flexibility to change them with almost zero to minimal code changes. The plug-in nature of modules also allows complex systems to be scaled up with new modules.

    During downtime, they can reduce the number of modules, which reduces costs and gives teams immense flexibility to manage that cost and resources over time. This is invaluable for changes like government compliance requirements that continually go into effect. Plug-and-play modules enable IT teams to maintain the continuous business processes.

    Ease of Maintenance

    Because of the standardization of the modular route, maintainability is considered an inherent part of system design. The ease with which a system is kept up efficiently and easily is crucial to IT teams, and modularity gives way to the maintainability of a product. New fixes or updates can be easily integrated in the independent modules and diagnosing quickly helps in reducing the turnaround time.

    The end business user also does not need to worry about the internal details of the modules. They should have a high-level knowledge of what the module does and can integrate it into their system without being bogged down with knowledge of the inner workings.

    Reuse, Reuse, Reuse

    Reusability is one of the biggest advantages of taking the modular route because the same functional unit can be used in various instances, making for rapid development and, ultimately, faster time-to-market.

    One real-life example of this is a company that needed a new connection to onboard new customers, which required custom configuration on the client’s end. Every time a new integration needed to be created, the process repeated. As any developer will tell you, the method was not scalable in the long run–and had massive maintainability issues. This is where the modular approach saved the day. The company designed a system where a new client connection could be configured using pre-existing modules and reused for multiple clients.

    Collaboration and Interchangeability

    Developers are not allowed to be one-person bands–the work requires constant teamwork across departments and teams. Modules are perfect for this–multiple teams can work simultaneously on different modules, which cuts down the laborious development cycle. Teams can work in different design patterns and develop unique solutions to improve product quality.

    Interchangeability goes hand in hand with this–the business user can change an existing module and use a different module with minimal effort to the business flow. Options are then increased for the end user, and they can choose from many different solutions.

    The modular pattern is not entirely new, but its success relies on the collective effort of IT teams and business leaders to do their part in designing and following a standard software framework. Only then will developers be able to take the modular route and deliver innovative, quality software for organizations across industries around the world.

  • Rezilion Updates Open Source MI-X Tool to Better Secure App Development

    Rezilion Updates Open Source MI-X Tool to Better Secure App Development

    Rezilion has updated its open source MI-X vulnerability discovery tool to include mitigation and remediation recommendations.

    In addition, the tool can now produce machine-readable output in either a JSON or CSV format.

    Finally, the company added Windows support for Heartbleed and SpookySSL vulnerabilities in Windows environments.

    MI-X makes it possible to use a command line interface (CLI) tool to identify and establish the exploitability of more than 20 well-known common vulnerabilities and exposures (CVEs).

    Yotam Perkal, director of vulnerability research for Rezilion, said Rezilion created the tool as part of its efforts to create a platform that enables organizations to better secure their software supply chains. The primary purpose of the platform is to prevent vulnerabilities from being introduced into applications in the first place by providing developers with the context required to understand the potential severity of a vulnerability, he added.

    There’s no doubt that developers need tools that enable them to easily identify vulnerabilities while writing code. However, shifting responsibility for vulnerabilities entirely left toward developers is not a panacea for application security. DevOps teams need to embrace DevSecOps best practices to ensure that the build created by multiple developers is secure and that the runtime environment where applications run is also free of malware.

    The challenge is that achieving that goal needs to go beyond adding additional tools to a DevOps workflow. The biggest challenge is narrowing the historic cultural divide between developers and cybersecurity teams tasked with discovering vulnerabilities. Most cybersecurity professionals don’t understand how applications are developed, so every instance of vulnerability found in an application looks the same to them—regardless of whether the actual code is externally accessible.

    DevOps teams, meanwhile, are trying to strike a delicate balance between patching innumerable vulnerabilities and building and deploying additional applications. More than anything, those teams need to be able to prioritize their patching efforts based on the actual versus theoretical severity of a vulnerability, noted Perkal.

    It may never be possible to address all the application security debt application environments have accrued over the years. However, as apps are built and application security issues are addressed more proactively, the state of cybersecurity should improve. The issue, of course, is that cybercriminals are now targeting software supply chains; inserting malware into a DevOps workflow creates a potential opportunity to compromise any number of downstream applications. Organizations are now racing against time to secure their software supply chains.

    The good news is that no developer intentionally sets out to build an insecure application. It’s just that far too many of them have been conditioned to think of security as an obstacle they need to overcome rather than address. However, the more tools they are provided to remediate as many vulnerabilities as possible, the better off everyone concerned will be.

  • ActiveState Makes All Tiers of Curated Artifact Repository Service Free

    ActiveState Makes All Tiers of Curated Artifact Repository Service Free

    ActiveState today announced it is making all tiers of its ActiveState Artifact Repository service available for free for a limited time. The move aims to enable organizations to better secure open source software components incorporated within applications.

    Loreli Cadapan, vice president of product for ActiveState, said the ActiveState Artifact Repository exposes a set of curated instances of open source software for creating binaries that are validated to be secure. That capability reduces the likelihood vulnerabilities will be inadvertently introduced into application environments by developers that have downloaded open source modules from repositories that may contain compromised code, she added.

    In addition, the ActiveState Artifact Repository also makes it possible to automatically generate software bills of materials (SBOMs) that identify which software components were used to build an application after all the code used to construct an application is stored in the repository, Cadapan noted.

    ActiveState’s repository is delivered as a cloud service to organizations that would otherwise have to build their own. Cadapan noted that the goal is to make managing and securing software supply chains simpler when more attacks are being launched against them.

    Most organizations have limited visibility into how they are consuming open source software. It’s become apparent many organizations have no idea what software components have been incorporated across their software supply chain. As a result, when a vulnerability is discovered, there’s no easy way for them to know whether they are impacted.

    However, awareness of this issue has risen, thanks to an executive order issued by the Biden administration which requires federal agencies to have an SBOM for every application they employ by next summer. The executive order was issued in the wake of a zero-day vulnerability in the Log4j tool discovered late last year that is widely used to create logs within Java applications. Many organizations are still looking for all the vulnerable instances of Log4j in their application environments. SBOMs must provide a list of the “ingredients” used to create an application to make it easier to find any component that might one day be similarly affected by a zero-day vulnerability.

    Organizations that want to implement a similar SBOM policy will spend massive amounts of time cataloging software on an ongoing basis. Every time an application is updated, there will be a need to once again verify what components are being employed within the context of larger DevSecOps workflows.

    SBOMs will undoubtedly play a critical role in improving overall application security. However, having an SBOM is not the same thing as operationalizing it. Organizations are ultimately hoping to be able to use an SBOM to decide whether to green-light the deployment of an application, so DevOps teams should expect to be required to not only provide an SBOM but also continuously update it. The challenge, of course, will be determining how many internal resources to devote to that effort versus relying on external platforms to manage that process.

  • Securing Open Source Components in a World of Mixed Committer Motivations

    Securing Open Source Components in a World of Mixed Committer Motivations

    Our world runs on software that contains open source components. This places an increased burden on developers, as the primary consumers and deployers of those components, to use code that is fully up-to-date and secure. The vast majority of open source committers with write access to project repositories remain focused on maintaining and making positive improvements to that code, while also helping to benefit the open source community as a whole. However, the sheer complexity of many open source projects has opened the door to different, more insidious and concerted types of attacks which could cause widespread and serious harm.

    Developers Have to Move Fast and Reuse Gives Them That Speed

    One complicating factor is the prevalence of reuse of third-party open source elements across the majority of open source projects through two main types of dependencies. With direct dependencies, an open source component links straight to a third-party code library, while transitive dependencies occur when a component calls out to a library that is, in turn, communicating with another dependency.

    Dependencies enable developers, under ever-increasing corporate pressure to deliver new software rapidly, to move faster by building on top of existing work by their peers. The downside is that those dependency foundations are vulnerable to attack, with some libraries perhaps under the aegis of a single committer for whom the code collection may be a side project and perhaps not attended to on a regular basis.

    Sonatype research and that of other organizations tells us that developers working with a Java application may be dealing with a staggering 1,500 dependency changes every year, with the average Java application containing 148 dependencies and the average Java project being updated 10 times annually. While the number of open source projects isn’t ballooning, the amount of versions of those projects is skyrocketing. The majority of vulnerabilities today impacting open source projects result from transitive dependencies, the more complex type of dependency.

    In an area where multiple projects may exist effectively solving the same issues, developers need to be aware of which projects are being actively maintained versus those that are either poorly nurtured or no longer in operation. On the other hand, successful open source projects may have tens or hundreds of committers with write repository access, which address a whole different set of issues, including reaching agreement on what a vulnerability consists of and how to fix or patch it.

    Amid a Community for Good, Bad Actors and Incidents of Self-Sabotage Emerge

    The reasons why individuals choose to commit to open source software are wide-ranging; a strong desire to give back to the community to a passionate and, perhaps very single-minded, hobby to an integral and paid part of a developer’s role and responsibilities at work. A few years ago, the concept of a malicious open source committer was an abstract theory. The thought back then was that perhaps a handful of ‘bad apples’ might exist within a community of millions of developers. However, since 2019, researchers’ tools and those of other organizations have identified over 100,000 malicious, suspicious or proof-of-concept packages, pointing to a much higher degree of behavior by cybercriminals.

    Bad actors are deliberately taking advantage of the complexity of open source software to knowingly introduce exploitable vulnerabilities. These attacks are growing in sophistication particularly in relation to malicious code injections into the source code of an open source library. These attacks can often appear as harmless code changes and remain hidden before delivering a malware payload. There is the recent example of a crypto heist that stole over $3 million in cryptocurrency which leveraged compromised access to a private GitHub repository.

    Protestware, where a code maintainer chooses to self-sabotage their open source project often to draw attention to a cause, whether geopolitical or specific to that individual, has become an issue over the past year. In this case, although the stated goal is not malicious hacking, real harm, in terms of major disruption, to developers using that code can occur.

    To counter both the impact of bad actors and of self-sabotage on open source components, developers need to take advantage of release integrity features to help protect themselves and their organizations from harm. They must be able to have full visibility and control over the software they build and the open source components that they are sourcing as part of that development work. At the same time, governments around the world, including in the U.S., are weighing into issues related to the security of software supply chains, so increased regulations and penalties should also factor into how developers and their organizations behave moving forward.

    We’re only one step away from the next potential Log4j attack, and every developer and organization needs to up their game and be ready to move fast on vulnerability identification and remediation. The gathering and sharing of data is what will help to increase everyone’s safety.

  • Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks Buys Cider Security to Lock Down Pipelines

    Palo Alto Networks this week extended its efforts to secure application environments by agreeing to acquire Cider Security, a provider of a platform for securing continuous integration/continuous delivery (CI/CD) platforms, for approximately $195 million in cash.

    The acquisition of Cider Security, scheduled to close this quarter, will extend the reach of the company’s Prisma Cloud platform that was updated last year to include a set of tools for securing infrastructure-as-code (IaC) used to provision IT infrastructure. Palo Alto Networks previously acquired Bridgecrew, which had developed an open source Checkov policy-as-code tool. Last month, Palo Alto Networks added software composition analysis tools to Prisma Cloud, as well.

    Cider Security developed what it described as an operating system for application security. The solution creates a graph that enables DevOps teams to visualize the relationships between all elements that make up a software development environment, including code. It then makes it possible to apply a set of controls to remediate any vulnerabilities and attack paths that might be identified using any number of third-party scanning tools.

    Palo Alto Networks CEO Nikesh Arora told industry analysts the acquisition is an example of the company doubling down on securing software supply chains alongside its existing portfolio of platforms and services for securing production environments.

    It’s not yet clear who is in charge of DevOps platform security, but increasingly there will be some type of central security function that works with application development teams to lock down software supply chains, said Mike Rothman, general manager for Techstrong Research, an arm of the parent company of devopsy.kinsta.cloud. “There’s going to be a central security group focused on securing the pipeline,” he said.

    As Palo Alto Networks continues to extend the reach of Prisma Cloud left, it continues to make a case for centralizing the management of cybersecurity through a portfolio of platforms that can be centrally managed via the cloud. It’s not clear how much organizations are centralizing management of security across their software supply chains and production environments, but Arora noted that interest in consolidating security vendors is high as organizations look to reduce the total cost of cybersecurity.

    In the meantime, organizations of all sizes are looking to employ DevSecOps best practices to better secure software supply chains in the wake of a series of recent high-profile breaches. In addition to scanning code for vulnerabilities, many of those organizations are starting to realize the tools and platforms used to build applications are also vulnerable to cyberattacks. The goal of those attacks is to insert malware that will manifest itself in any number of downstream applications that are eventually deployed in a production environment.

    It’s not yet apparent just how compromised those tools and platforms may be, but it’s clear software consumers are moving toward holding developers more accountable for vulnerabilities. The best-known example of those requirements is an executive order issued by the Biden administration that will require federal agencies to include software bills of materials (SBOMs) that list known vulnerabilities. Many enterprise IT organizations are expected to adopt similar requirements.

    One way or another, however, the tools and platforms that make up a software supply chain, along with the code they produce, are going to be subject to much greater scrutiny than ever before.

  • JFrog Gives Pyrsia to CD Foundation to Secure Software Supply Chains

    JFrog Gives Pyrsia to CD Foundation to Secure Software Supply Chains

    At the KubeCon + CloudNativeCon North America conference this week, JFrog announced it contributed the Pyrsia project, which uses blockchain technologies to secure software packages, to the Continuous Delivery (CD) Foundation.

    Stephen Chin, vice president of developer relations at JFrog and governing board member for the CD Foundation, said the goal is to increase the number of contributors to the project. Current contributors to the Pyrsia project include Docker, Inc., DeployHub, Futurewei and Oracle.

    As part of those efforts, the CD Foundation will bring a centralized governance model through which a roadmap for the project will be defined.

    Pyrsia provides IT teams with a decentralized blockchain network to access an immutable software package repository that is designed to seamlessly integrate with the package management systems developers already employ. It creates a digitally signed, immutable chain of evidence for code that can be incorporated into a software bill of materials.

    Securing software supply chains became a more urgent issue following the discovery last year of the zero-day Log4Shell vulnerability that impacted Java applications. Many developers routinely reuse open source software, but many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited; the onus for making sure that software is secure falls on the organizations that decide to deploy it.

    The trouble is, many organizations that rely on open source software assume it is more secure than it really is. Initiatives like Project Pyrsia are part of a larger effort to make it simpler for maintainers to secure open source software.

    It’s not clear to what degree security concerns are prompting organizations to review the amount of open source software they consume. Most organizations are more dependent on open source software than they realize, as most packaged applications include a large amount of open source code that is downloaded from any number of repositories. Whenever a zero-day vulnerability is discovered, organizations can easily spend months looking for all the instances of an open source component that might be vulnerable.

    In theory, blockchain platforms and DevSecOps best practices should make it easier to secure software packages by reducing the number of vulnerabilities in production environments. The challenge organizations face today is the amount of technical security debt that exists due to vulnerabilities in legacy applications. It might be close to a decade before applications based on more secure code replace existing solutions.

    In the meantime, multiple approaches to securing software supply chains are advancing, including the use of some type of immutable platform. It may be a while before those platforms are widely incorporated into software supply chains, but it’s apparent that it’s now more a question of how long it will take rather than if those technologies will be applied to securing software development environments.

  • Sonatype Report Surfaces Scope of Known Vulnerability Challenge

    Sonatype Report Surfaces Scope of Known Vulnerability Challenge

    Sonatype this week published a State of the Software Supply Chain Report that found a 633% year-over-year increase in malicious attacks aimed at open source software residing in public repositories.

    In addition, Sonatype launched a Sonatype Safety Rating system that employs machine learning algorithms and other metrics to identify the most secure open source components stored in those repositories.

    The report found 96% of open source Java downloads have known vulnerabilities that could have been avoided if an available, more secure version had been used. Collectively, the report estimated there were 1.2 billion known-vulnerable dependencies that could be avoided if developers had only been aware that a later version of a software component was available.

    According to the report, the average Java application contains 148 dependencies. Updates to Java applications are, on average, made 10 times a year, so development teams are being asked to track 1,500 dependency changes per year.

    Sonatype CTO Brian Fox said the report makes it clear that organizations are not assuming enough responsibility for using open source software that has known vulnerabilities. In effect, organizations are blindly and recklessly using software components without any real appreciation of the associated risks, he said.

    Rather than a knee-jerk reaction to each new zero-day vulnerability that is discovered, Fox said, IT teams need to focus on putting processes in place to make sure the latest, most secure edition of any given software module is being used. A survey of 662 engineering professionals included with the report, however, found 68% of respondents were confident that their applications were not using known vulnerable libraries. Nevertheless, a random sample of enterprise applications conducted by Sonatype found 68% contained known vulnerabilities.

    Overall, the report surmised that consumption of open source software will soon surge past an estimated 3.1 trillion total requests, with six out of every seven vulnerabilities being the result of a transitive dependency created by indirect relationships between software components. At the current rate of consumption, it’s fairly clear that the processes used to build and deploy applications today are insane given how dependent organizations are on applications, said Fox.

    In the wake of a series of high-profile security breaches, there is, fortunately, a lot more focus on securing software supply chains today than there was this time last year. The scope of the challenge, however, is mind-boggling when you consider the totality of applications already deployed in application environments that have known vulnerabilities. Organizations need to first make sure they are remediating vulnerabilities in their most critical applications while at the same time implementing DevSecOps best practices. This will ensure as few vulnerabilities as possible find their way into the next generation of applications.

    Obviously, these application security issues are not going to be resolved overnight. DevOps teams will be spending the next several years addressing a level of technical security debt that has been allowed to accrue for more years than anyone in IT really cares to admit.

  • Making SBOMs Actionable

    Making SBOMs Actionable

    A software bill of materials (SBOM) is a list of all the software components found in a given codebase or used in a given software build. Great. So, now what? Why do we even care about SBOMs?

    Those are great questions—because in and of itself, the SBOM doesn’t really do anything; it is simply a means to an end. That end being greater software security and a more secure software supply chain.

    Let’s take one step back to understand why there is such a sudden and urgent demand for SBOMs. The most recent ‘big bang’ attack on the software supply chain was the Apache Log4j flaw, discovered in December 2021. That vulnerability opened the doors to countless breaches and caused billions of dollars in damage. Before that, the high-profile hacking of SolarWinds caused similar damage.

    Now, will the SBOM prevent that from happening (again)? No. However, what an SBOM can do is tell you exactly where these kinds of vulnerabilities exist in software and enable you to quickly patch your systems or block exploits. Having a software bill of materials enables you to quickly assess the risks in your codebase and mitigate them as needed.

    It’s strongly recommended that you use dynamic SBOMs (versus static) that are automatically updated to the latest SBOM information and provide extensive search capabilities as part of an SBOM database. That allows for immediate identification of a specific dependency version, like the Log4j case. Some solutions also update the SBOM information based on the runtime (like Docker or Kubernetes). That way, you know not only if some component is used, but also where.

    SBOMs are an invaluable tool as they allow an audit of licenses, libraries, modules, applied patches and other components to look for weaknesses. However, for such an audit to reliably trace the components used to build the software, the SBOM must have certain attributes.

    • Unique identities for each software component
    • Separate identities (independent of those used internally in the organization) to identify each machine and user involved in the development process
    • Timestamps to facilitate traceability of each change or component incorporation

    Additionally, from a security point of view, a key element necessary for the reliability of the SBOM is to prevent unauthorized changes to it. And the most effective way to do this is by using an immutable ledger that records a history of when each change was made.

    Once the reliability of an SBOM is assured, DevSecOps teams can use it as part of their threat scanning toolbox and, therefore, improve software security.

    There is no doubt that SBOMs should be requested from your software vendors and that you should consider creating SBOMs along with your own developed software. It’s all about the proper storage of the SBOMs so you can be sure they’re recent, searchable and trustworthy and tamper-proof.

    The benefits and use cases for SBOMs are numerous; they vary across stakeholders who produce, choose and operate software and are amplified when combined. Use cases for SBOMs include better software development, supply chain management, vulnerability management, asset management and high assurance processes. The benefits include reducing cost, mitigating security risk, license risk and compliance risk.

    But the key is making the SBOM actionable.

    No developer, no software maintainer or DevOps engineer wants to manually collect the dependencies and produce SBOM documents. It needs to be fully automated within the software build and deployment pipeline and there needs to be a proactive check of where it’s currently running.

    The most efficient approach to work with a pervasive SBOM policy is to have them generated as a byproduct of a modern development CI/CD process.

    In today’s complex development environments, it is imperative that SBOMs can be shared frictionlessly between teams and organizations as a fundamental part of software management transparency. This transparency model is supported by the ISO association through its OpenChain Specification, and it is part of an effort to improve security in the digital industry.

    There are two SBOM specifications: The Software Package Data Exchange (SPDX) backed by the Linux Foundation and the CycloneDX specification managed by the CycloneDX Core working group. For more details, have a look here.

    Make sure to choose the SBOM standard that makes the most sense for you and stick to that for all of the software developed or used in your infrastructure. The test of whether your SBOM is actionable will come when the next Log4j moment arrives. You should be able to pinpoint the existence and the location of the component in question to mitigate risk effectively.

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2022 – October 24-28, 2022