The survey, Anchore’s 2024 Software Supply Chain Security Report, also found that less than half of respondents are following supply chain best practices like creating software bill-of-materials (SBOMs) for the software they develop (49% of respondents) or for open source projects they use (45%) of respondents. Additionally, only 41% of respondents request SBOMs from the third-party vendors they use. Despite these low numbers, this is a significant improvement from 2022’s survey, when less than a third of respondents were following these practices. 

The report found that 78% of respondents are planning on increasing their use of SBOMs in the next 18 months, and 32% of them plan to significantly increase use. 

“The SBOM is now a critical component of software supply chain security. An SBOM provides visibility into software ingredients and is a foundation for understanding software vulnerabilities and risks,” Anchore wrote in the report.

The report also found that currently 76% of respondents are prioritizing software supply chain security.

Many companies are having to make this a priority as part of their efforts to comply with regulations. According to the report, organizations are now having to comply with an average of 4.9 regulations and standards, putting more pressure on them to get security right. 

Of the companies surveyed, more than half have a cross-functional (51%) or fully dedicated team (8%) that works on supply chain security. 

Finally, 77% of respondents are worried about how embedded AI libraries will impact their software supply chain security.  

For the survey, Anchore interviewed 106 leaders and practitioners that are involved in software supply chain security at their company.

The post Report: Only 1 in 5 organizations have full visibility into their software supply chain appeared first on SD Times.

This new free tool automates the process of creating SBOMs. Developers give the SBOM Manager access to their code repositories and it will create an SBOM that includes inventories of components, vulnerabilities, and licenses. Alternatively, they can import an existing SBOM file to speed up the process. 

Once created, owners can edit the details, add custom metadata, and catalog components so that they can be used across different SBOM. 

They can also define custom licenses and manage open source license risks, obsolescence, and copyrights. 

The created SBOMs can be exported into various formats including Excel, Word, PPT, and CycloneDX. 

The platform also includes an interactive dashboard that provides at-a-glance insights of component categories, vulnerabilities, and licenses. 

“The product leverages advanced software intelligence to provide an automated, customizable, and user-friendly approach to SBOM management,” said Greg Rivera, vice president of CAST. “This product is intended for organizations that need to generate and maintain accurate SBOMs without the complexity and high costs associated with traditional solutions.”

You may also like…

Companies still need to work on security fundamentals to win in the supply chain security fight

The post CAST simplifies SBOM creation with new free tool appeared first on SD Times.

The project was created jointly by the Open Source Security Foundation (OpenSSF), Cybersecurity and Infrastructure Security Agency (CISA), and the Department of Homeland Security Science and Technology Directorate (DHS S&T). 

Protobom allows companies to read software bill of materials (SBOM) data, create their own SBOMs, and translate SBOMs into different standard formats. 

According to OpenSSF, there are many SBOM formats and schemas out there, which can be challenging for companies. The goal of the new project is to provide a “format-neutral data layer on top of the standards that lets applications work seamlessly with any kind of SBOM.”

OpenSSF also explained that by integrating Protobom into applications that link SBOM and vulnerability information, organizations will be able to more quickly access the necessary patches and mitigations to keep their software supply chains safe. 

“Vulnerabilities in software are a key risk in cybersecurity, with known exploits being a primary path for bad actors to inflict a range of harms. By leveraging SBOMs as key elements of software security, we can mitigate the risk to the software supply chain and respond to new risks faster, and more efficiently,” said Allan Friedman, senior advisor and strategist at CISA. “Protobom is a step towards greater efficiency and interoperability by translating across the widely used formats so that tools and organizations can focus on what’s important. It is a positive solution that helps shape a more transparent software-driven world.”

Omkhar Arasaratnam, general manager of OpenSSF, added: “Protobom not only simplifies SBOM creation, but also empowers organizations to proactively manage the risk of their open source dependencies. The security of open source software requires partnership between the public sector, private sector and the community. The OpenSSF is proud to be a part of this mission.”

The post OpenSSF, CISA, and DHS collaborate on new open-source project for creating SBOMs appeared first on SD Times.

To minimize inconsistencies and encourage greater transparency, three primary SBOM formats have emerged, each of which allow companies to generate, share, and consume supply chain data. Before you choose, it’s important to understand what the current SBOM format options are and how they are best suited to you.

Here, we’ll explore all three formats – SPDX, CDX, and SWID – share their attributes and weaknesses, and offer guidance to help you find the perfect match. 

First, let’s discuss why there are so many different formats. The simplest reason is that guidance around the use and requirements of SBOMs is still quite new. While SBOMs have been around for a while, it was less than two years ago that the software bill of materials was advanced by NIST in accordance with the Biden administration’s Executive Order on Improving the Nation’s Cybersecurity. Since then, government agencies have released guidance that increasingly requires SBOMs. That, combined with ever-expanding use of open source software components, will drive increased SBOM adoption and subsequently greater demand for a standardized format. Until that time, organizations have three predominant formats to choose from.

Software package data exchange (SPDX)

What is it? SPDX is a data exchange format created to easily share information about software packages and related content including components, licenses, copyrights, security references, and other metadata. It is intended to save time and improve data accuracy in support of supply chain transparency.   

What are its origins? SPDX is authored by the SPDX workgroup, a community driven project supported by the Linux Foundation. 

What are its best features? Using a standardized, machine-readable format ensures consistency across different organizations and reduces the need to reformat information, makes it easier to share, and consequently improves compliance and security efficiency. 

Its size and capacity make it a particularly flexible option. One of its biggest strengths is the ability to provide a detailed big picture of your software supply chain, components, and dependencies.  SPDX identifies the software package, package level, file-level licensing, and copyright data, and also shows the file creator, and when and how it was created. This allows for a multiplicity of annotations and the most detail of the three formats. 

Of the three main SBOM formats, SPDX is the largest and most robust and is the only format with an ISO (International Organization for Standardization) accreditation. 

Potential weaknesses: There aren’t really any notable weaknesses with this all-inclusive format. 

Best suited to: Primarily designed to improve license compliance, SPDX is typically used by large, complex organizations. Linux users naturally tend to adopt SPDX, and it is preferred by those that build commercial software or operate enterprise software. SPDX adoption is growing significantly as the use of open source projects increases. 

CycloneDX (CDX)

What is it? CycloneDX is a full-stack bill of materials standard.

What are its origins? CycloneDX is backed and maintained by the OWASP Foundation. 

What are its best features? A main differentiator of CDX is its broad support of various specifications including SBOM, Software-as-a-Service Bill of Materials (SaaSBOM), Hardware Bill of Materials (HBOM), Operations Bill of Materials (OBOM) and VEX use cases. The format identifies BOM metadata, components, services, dependencies, compositions, vulnerabilities, and extensions.

The CycloneDX format provides standards in XML Schema, JSON Schema, and protocol buffers. The project also supports various community-supported tools and extensions that target specialized or industry-specific use cases. 

Like SPDX, there is strong community direction and development. Additionally, the involvement of the OWASP Foundation provides educational support opportunities which help to ensure continuous development and advancement of SBOM.

Potential weaknesses: CDX offers many of the same attributes and capabilities as SPDX but is not quite as robust. 

Best suited to: Preferred by nimbler organizations and by teams that use open source heavily, CDX is more agile and easier to use than SPDX. 

Software Identification Tags (SWID) 

What is it? SWID is an industry standard that allows organizations to track the software inventories installed on managed devices with a simple, easy-to-use format. SWID tag files contain descriptive information about a specific release of a software product, including an end tag to define the product lifecycle. There are four types of SWID tags: 

1. Primary Tag: Identifies and describes a software product installed on a computing device. 
2. Patch Tag: Identifies and describes an installed patch that has made incremental changes to a software product installed on a computing device. 
3. Corpus Tag: Identifies and describes an installable software product in its pre-installation state. It can be used to represent metadata about an installation package or installer for a software product, a software update, or a patch. 
4. Supplemental Tag: Allows additional information to be associated with another SWID tag to ensure Primary and Patch Tags provided by a software provider are not modified by software management tools, while allowing these tools to provide their own software metadata.

What are its origins? SWID was created and is maintained by the National Institute of Standards and Technology (NIST).

What are its best features? Because SWID’s primary purpose is inventory, it is far less complex than SPDX and CycloneDX and therefore is faster and easier to use. 

SWID is widely used by standards bodies such as the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF). 

Potential weaknesses: Its capabilities are limited, and it doesn’t provide details such as vulnerability information, annotations, or license information. 

Best suited to: For organizations that want to create an inventory of software components and dependencies quickly and easily, SWID is a good option. 

Which SBOM will you choose?

Each of these three formats serve the purposes of an SBOM though some offer additional capabilities that go beyond those requirements. Before making your choice, consider your organization’s specific needs. For example, organizations in highly regulated fields, e.g., financial services or healthcare, and most government agencies require a greater level of granularity and detail than may be available with the SWID format. This may also be the case in an M&A situation. However, a simple format may be enough to provide peace of mind to a prospect or customer.

No matter which format, or combination of formats, you choose, there’s no doubt SBOMs will play an increasingly important role in the development and security of software and the software supply chain. To ensure your organization is ready, it’s important to get started with an SBOM today.

The post When only one SBOM will do, consider these formats appeared first on SD Times.

This includes the general availability of Snyk Cloud, which offers tools to help fix software vulnerabilities such as a vulnerability scanner and a patch management system that was launched in July 2022 with limited availability. 

The innovations also include capabilities that can secure the software supply chain (SSC) such as the ability to simplify emerging requirements around SBOMs and improved reporting features that allow for greater visibility and governance for developer security programs. 

The new SBOM features include an API and CLI that generates SBOMs, scans standard SBOMs to identify security vulnerabilities for free, and also scans SBOMs with the open-source application Bomber and then tests the using the Snyk Vulnerability Database. 

“Snyk was founded on the belief that the developers building our collective future should also be empowered and equipped to secure it,” said Adi Sharabani, the chief technology officer at Snyk. “We’re proud to share today’s latest significant developments to help our global customers continue their pace of innovation securely.”

Snyk also announced that it is committed to driving DevSecOps success and introduced two new offerings as part of the asset collection Snyk Learn: Snyk Accelerate as a 90-day installation and best practice review and Snyk Premium, a high-touch service bundle. 

The post Snyk announces updates to its Developer Security Platform appeared first on SD Times.

The rise in software supply chain attacks, like the SolarWinds hack, prompted last year’s executive order requiring vendors to provide a software bill of materials (SBOM). This software “ingredients list” can help security teams understand if a newly disclosed vulnerability impacts them. However, industry experts caution that it isn’t comprehensive enough to prevent attacks or address the challenges of securing today’s dynamic software supply chains.

“The introduction of SBOM is an important step, however, it isn’t sufficient to ensure the security and integrity of software supply chains,” said Admiral Mike Rogers, former director of the NSA. “Recent high-profile breaches — like those that affected SolarWinds, Codecov and  Log4j — could not have been detected or prevented with the static list of software components contained in an SBOM. There’s a real risk of providing a false sense of protection by having a standard for compliance that does not equate to security.”

To address these issues, OX is developing a new open standard, PBOM, in collaboration with leading cybersecurity-conscious companies. The Pipeline Bill of Materials (PBOM) includes within it the SBOM but goes further, covering not only the code in the final product but also the procedures and processes that impacted the software throughout its development. OX and its partners undertook extensive research on the root causes of more than 70 attacks from the past year. They specifically designed the PBOM to contain the information that would have been needed to prevent each of the recent attacks.

OX’s platform is the first product using the PBOM standard to provide end-to-end software supply chain security, allowing it to cover every step of the development pipeline, from the earliest planning stages until deployment to production. OX seamlessly integrates with existing tools and infrastructure to monitor and record every action affecting software throughout the entire development lifecycle. It gives security and DevOps teams complete visibility and control over the attack surface, including source code, pipeline, artifacts, container images, runtime assets, and applications.

“Developers and DevOps make constant changes to the software supply chain, adding new tools, open source components and SaaS services,” said Neatsun Ziv, OX’s CEO and co-founder. “The OX platform gives DevSecOps teams real-time, end-to-end visibility into all aspects that impact software through the entire pipeline, so they have the necessary context and control to ensure security.”

OX connects to an organization’s code repository and performs a scan of the environment from code to cloud, to automatically produce a full mapping of assets, apps and pipelines. OX identifies which security tools are in use, verifies they’re all connected and operational, and determines if additional tools are necessary. Following the scan, OX presents any security issues that were found, prioritized by their business impact, alongside context, automated fixes and recommendations, empowering DevSecOps teams to tackle their cybersecurity backlog. A PBOM, which includes an SBOM, version lineage, SaaSBOM, build hashes and more, can be automatically generated and shared with internal stakeholders or customers, so they in turn can verify that the software they use is derived from trusted, secure builds.

“Ox Security is tackling a critical challenge facing companies today, and are uniquely positioned to become leaders in their space,” said Nadav Zafrir, Managing Partner at Team8 Group and former head of Israel’s elite intelligence Unit 8200. “We are thrilled to join forces with Neatsun and Lior. The ground-breaking PBOM standard enables OX’s platform to provide unparalleled security coverage and I have no doubt that PBOM will be widely adopted across the industry.”

Additional quotes:

“Supply chain attacks are on the rise, and the attack surface is growing,” said Mony Hassid, Managing Partner at M12, Microsoft’s venture fund. “When it comes to software security and integrity, you have to look beyond which components were used and consider the overall security posture throughout the development process. Ox Security is pioneering a standard that will be transformative for supply chain security. We’re proud to work with OX to improve software security.”

“The cybersecurity industry has been playing catch-up so far by pursuing a never-ending process of patching production environments and chasing alerts, issues and fixes,” said Karthik Subramanian, General Partner at Evolution Equity Partners. “OX’s groundbreaking approach brings control back to DevSecOps teams by providing visibility and complete control over an organization’s code. The level of innovation in OX’s platform is truly remarkable and provides value to everyone in an organization — from developers to DevSecOps teams to executives.”

“I believe the PBOM standard will reverse the tide,” said Mario Duarte, Vice-President of Security at Snowflake. “I am proud to take part in a project that can have such a major impact on the future security landscape, and to share our knowledge and expertise.”

“OX is truly changing how software supply chains are protected, ensuring that all code comes from secure and trusted builds,” said Naor Penso, Senior Director of Product Security at leading applied analytics company FICO. “The OX platform prevents software supply chain attacks while accelerating and streamlining development. The PBOM framework created by OX, expands the traditional SBOM with contextual knowledge and true end-to-end lineage that drives assurance in software security across its entire life-cycle.

The post Ox Security emerges from stealth with $34M to provide end-to-end software supply chain security appeared first on SD Times.

BOMs have been used for years by organizations; they are a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product. 

In today’s software world, it applies to all the code that goes into an application, license requirements for third-party components, dependencies on other components, and compliance with any other industry-specific regulations. According to a May 2021 executive order from U.S. President Joe Biden aimed at tightening up cybersecurity, “an SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software.”

Michael White, technical director and principal architect at the Software Integrity Group at Synopsys, said there are a couple of different ways to look at SBOMs – either as a static artifact or report, or as a process. “As we add components into our software, or change the version of the components, or update the components, we should be maintaining that SBOM on an ongoing basis,” he said. The continual process of software maintenance, he pointed out, saves you from having to scramble to assemble all the information about changes. As a continual process, you’re building up the SBOM piece by piece as you go along.

As for what SBOMs mean for developers, White said those are the people who are in the middle of the supply chain, as producers of software and consumers of software used to create their applications. As such, they have to worry about two different sets of obligations, White explained. “They have to worry about doing what they’re required to do for the end user of our product. But then also, are we passing that requirement down to the people that we consume software from?” 

With open source, that could be in the form of generating export information about a particular package; with commercial software, an organization should have the requirement that the supplier provide an SBOM. “That kind of information should kind of filter down the supply chain so that the information kind of bubbles up again.”

Today’s modern software comes with a long tail of dependencies, and studies have shown that as much as 90% of a modern application today is not written as first-party code by your development team, White said. “The SBOM does have to include your own components, the things you’re developing,” he said, as well as components assembled from other sources.

White said Synopsys talks more about building trust than simply discussing security, because organizations also have to think about safety, quality, compliance – and how to make that available to developers.

“We’re very much about the developer experience,” White said. “So, surfacing up that information at the right time, providing meaningful feedback that tells developers about something they can understand and act on. Once that is embedded and visible in the process, a lot of other concerns go away. It keeps the security people happy, it keeps the market compliance people happy, and the legal team and risk team happy.”

With its platform, White said, Synopsys is building the bridge between developers and the other stakeholders in an application to ensure those requirements are being met as well.

Content provided by SD Times and Synopsys

The post SBOMs can help ensure software integrity appeared first on SD Times.

This is according to a report by The Linux Foundation, OpenSSF, SPDX, and OpenChain titled “The State of Software Bill of Materials and Cybersecurity Readiness,” which surveyed 412 organizations globally.  

A SBOM is metadata that identifies a software component and its contents that can be shared across an organization and provides transparency into software supply chains. 

According to survey respondents, the top three benefits of having a SBOM include making it easier for developers to understand dependencies, monitor components for vulnerabilities, and manage license compliance. 

While 82% of survey participants are familiar with SBOMs, only 47% are producing or consuming them. However, it looks like companies are starting to move in the right direction, with 78% of organizations expecting to produce or consume SBOMs this year. This would be a 66% increase from last year. 

“SBOMs are no longer optional. Our Linux Foundation Research team revealed 78% of organizations expect to produce or consume SBOMs in 2022,” said Jim Zemlin, executive director at the Linux Foundation. “Businesses accelerating SBOM adoption following the publication of the new ISO standard (5962) or the White House Executive Order, are not only improving the quality of their software, they are better preparing themselves to thwart adversarial attacks following new open source vulnerability disclosures like those tied to log4j.”

Many organizations are looking for a greater consensus from the industry when it comes to SBOMs. Sixty-two percent of respondents want better consensus on how to integrate SBOMs into DevOps practices, 58% want consensus on integration into risk and compliance processes, and 53% want better consensus on how SBOMs will evolve. 

The post Report: Fewer than half of companies are creating or using a software bill of materials appeared first on SD Times.

According to Brian Fox, chief technology officer at Sonatype, while some may think it is a trivial requirement, it provides transparency not only to your end users, but to your business. Any good software security program will tell you that you have to understand all the components in your system and the risks associated with those components. When a majority of the software assembled today is made up of open-source software or third-party code, a SBOM is the only way to provide full visibility into what is inside. 

“Security is a knowledge warfare game more than anything, so we need to make it easier for people to understand what’s inside the software that they’re deploying on their networks, in their car, in their hearts, in their insulin pumps,” said Fox. “These things are not so readily observable so requiring an SBOM is a step towards providing that transparency.” 

Unfortunately, less than 50% of companies actually produce a SBOM, but it is something that they will soon no longer be able to ignore. President Biden recently signed a United States cybersecurity executive order that requires any business that produces or sells software to the federal government to provide an SBOM along with the application.  

“Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk,” the order states. 

Fox hopes that the executive order will be a step forward to translating the importance of the SBOM to the broader software community.

The executive order follows the recent software supply chain attacks on SolarWinds and Codecov, as well as the ransomware attack on the Colonial Pipeline, all of which impacted a number of federal agencies and businesses. 

“The attacks we are seeing in the software supply chain are attacking developers and development infrastructure. So many application security programs are focused on defending against shipping stuff to their end users that might cause data leakage and cause customers to be hacked, but as we have seen with SolarWinds, the developers are the target,” said Fox. 

How to successfully produce a software bill of materials

The traditional approach to application security is to scan an application before it ships or goes into production, but that’s an old school mentality that creates a bill of vulnerabilities, not a bill of materials. “You are going to miss stuff if you can’t precisely detect what you are looking for,” said Fox. 

He explained the key to successfully producing an SBOM is through automation. If you are doing it manually, you are doing it wrong because there are so many components that go into software, it’s almost impossible to find them all and then manage it. “When all these things are changing weekly, monthly, by the time you are done, you have to start all over. It’s just not possible to do it by hand,” Fox added.

The tools you incorporate to automatically produce a software bill of materials have to be precise and have to analyze existing applications. If you are using open-source software like Apache Struts that has a number of subcomponents and you are only using a few of them, your tool needs to know exactly what those components are otherwise it will give you a bunch of false positives for components that aren’t in your system. 

“At Sonatype, we try to go to the next level and understand where does the vulnerability actually lie in the code, and then understand which of the individual subcomponents it is in and whether or not you have a potential vulnerability,” said Fox. “We’ve created a dataset that is precise enough to be actionable and automated to make that connection.” 

The company also recently announced support for the CycloneDX Software Bill of Materials Standard, which worked with a number of stakeholders including Sonatype to provide a practical standard that can facilitate interoperability between systems.  

Fox hopes companies will take the executive order seriously and not just try to check the box and put it on their website. “If a vendor gives you a bill of materials, you have to trust it because you can’t verify that it is accurate. I fear a lot of companies will move towards just putting it together so it’s good enough,”  he said.

However, he does note that the executive order is a great start for getting the awareness around SBOMs and having people understand it. “These types of things can finally move the needle for the industry even if they didn’t really want to,” he said. 

Content provided by SD Times and Sonatype

The post Protect your users and your business with a software bill of materials appeared first on SD Times.