devopsy.kinsta.cloud

Tag: Software Supply Chain

  • SBOMs 101: What You Need to Know

    SBOMs 101: What You Need to Know

    Recent security incidents have the industry buzzing about the lack of knowledge about code dependencies, attacks on the software supply chain, software bills of materials (SBOM), digital signatures, provenance, attestation and the like. The fact is, every time a new vulnerability appears a lot of time and effort is required to detect not just when, where and how the vulnerability occurred, but also to measure the real impact on the applications and services that are running in our environments.

    What if we had a way to enumerate all the software components we used and produced that could be distributed and consumed easily? This is the problem SBOMs are trying to solve.

    What is a Software Bill of Materials (SBOM)?

    An SBOM is simply an artifact containing a comprehensive list of package dependencies, files, licenses and other assets that, together, make up a piece of software. Think of an ingredients list, but for software.

    The NTIA defines an SBOM as a formal record that contains the details and supply chain relationships of various components used in building software. These components, including libraries and modules, can be open source or proprietary, free or paid and the data can be widely available or access-restricted.

    This concept is nothing new, and bills of materials (BOMs) are a common, existing part of industrial processes. They are very similar to a list of ingredients, although a BOM usually includes the concept of hierarchy, as well. Every component is broken down into a list of subcomponents, each of which also includes their own BOM.

    In SBOMs, the pieces are commonly abstract libraries, modules, binaries, compilers, files, etc., and they usually include licensing information (Apache 2.0, GNU, BSD, etc.) and additional metadata.

    SBOM History

    SBOMs might seem new, but the open source community realized the need for such a thing and created SBOMs more than 10 years ago. The Software Package Data Exchange (SPDX) standard was created in 2010 to communicate SBOM information including components, licenses, copyrights and security references.

    In recent years, the issue has come to the fore due to the increase of attacks related to the supply chain. Here’s a short timeline.

    SBOM Timeline

    And this is just the beginning. 2022 is becoming a turning point in how the industry is approaching SBOM and software supply chain security challenges.

    Where Does the SBOM Apply?

    An SBOM applies to any software component, either external or internal, open source or proprietary files, packages, modules or shared libraries used in the construction of software products. This includes firmware and embedded software, too. Hardware might take part in the distribution or execution of software (network equipment, cryptographic devices, chips, etc.) but is not considered part of an SBOM, although standards like CycloneDX support devices as a type of component.

    In an ideal world, every software company would attach an SBOM to each deliverable, and everyone would have full visibility into the components used in the software. That would enable knowledge of exactly which vulnerabilities are impacting that software.
    But we are not in that ideal world.

    Typical Assets With SBOMs

    ● Development dependencies. Every time a developer includes a third-party dependency (either open source or an internal component), it is often adding transitive dependencies – the modules or packages that the dependency itself is using. So, a detailed SBOM would enable visibility into those transitive dependencies, as well.
    ● Software applications or packages. When an application is distributed, the SBOM would help the consumer quickly identify the application version, helper tools that are included in the package and all the pieces that were involved in the build process. This makes it much easier to identify vulnerabilities or troubleshoot issues that might be caused by buggy software dependencies.
    ● Container images. Container images are basically a filesystem composed of a base image distribution plus a set of additional packages and components added during the build process.
    ● Hosts. Hosts include, for example, virtual machine appliance images, an AWS AMI and the like. The SBOM would include the base operating system type, vendor, version and a comprehensive list of each package installed in the host, either from the base operating system (e.g., the Linux distribution) or manually deployed from external sources.
    ● Hardware devices. Examples include a firewall, an IoT device or a mobile phone that is running software.

    SBOMs should capture any and all multi-level dependencies. So, for example, if package libfoobar-1.5.3-r3-u8 is part of the SBOM, it should also include each package name, version, license, etc. used to assemble libfoobar-1.5.3-r3-u8, and the components for each of these, resulting in a multi-level tree where each node is decomposed into its dependencies.

    It is also important to point out that every time one of these assets changes—every release of a product or even each build—a new SBOM should be created to match the changes for that version.

    Why You Need an SBOM

    You need an SBOM for the same reason you need a list of ingredients for food. You can check for the presence of allergens, the presence of animal-based substances (for vegans), chemical preservatives, etc. Certainly, you can eat food without checking the list of ingredients, but you are assuming some risks. The same applies to software: It might be fine to use a dependency for a quick test in a sandbox environment, but you definitely want to know what’s inside when deploying critical services to production or delivering software in environments with strong compliance regulations.

    Without an SBOM, you don’t have that visibility. A piece of software becomes an impenetrable black box with respect to the packages and libraries that are used to assemble it.

    The availability of an SBOM for third-party dependencies makes it easier to build an SBOM for your software by simply adding your own ‘ingredients’ to the existing list of dependencies. Of course, your software can also be the input or dependency of a more complex product, and consumers might demand the presence of an SBOM as part of their supplier’s requirements.

    Knowing which licenses are necessary for the different software pieces is also very important. Otherwise, distributing software using third-party libraries under multiple license types might break the usage terms or force you to make source code public, which can be inconvenient and even get your company into trouble.

    Finally, the SBOM is a key element of the vulnerability scanning process. Provided that you have an accurate SBOM and reliable and updated vulnerability feeds from different vendors and sources, it is pretty straightforward to find which vulnerabilities are present in the software. Without an SBOM, the vulnerability scanning software needs to compute and guess; making its own inaccurate version of an SBOM, which might be quite tricky or even impossible for some components.

    A good SBOM should allow organizations to answer questions like, “Am I vulnerable to the CVE-2022-22965 (Spring4Shell) vulnerability?” Exploiting this vulnerability requires a set of conditions to happen simultaneously in the host or container running the exploitable Java package:

    ● Using SpringCore versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 or older, unsupported versions
    ● Using JDK 9 or higher
    ● Running Apache Tomcat as the Servlet container
    ● Having the library packaged as WAR
    ● Using the spring-webmvc or spring-webflux dependency

    Most of these conditions can be checked for in the contents of a comprehensive SBOM, making it easier to assess the risk in your environments by focusing on fixing the exploitable applications first.

    Creating an SBOM

    Currently, generating SBOMs is complex because there are multiple competing standards, distributions, etc. that make adoption slower than desired.

    Many tools exist that can help you create an SBOM for a piece of software. Before you even consider producing an SBOM, it is critical that the build process is completely automated (Level 1 in the SLSA framework) and SBOM creation is integrated as part of the build pipeline.

    Next, these are some example executions and outputs of open source tools and the corresponding SPDX or CycloneDX (truncated) SBOM, which are two of the most common standards.

    Syft

    Syft can generate an SBOM in SPDX or CycloneDX format from a filesystem or container image, and it is embedded in Docker by default using the docker sbom command.

    $ syft neo4j:latest
    ✔ Parsed image
    ✔ Cataloged packages [376 packages]
    NAME VERSION TYPE
    CodePointIM 11.0.15 java-archive
    FastInfoset 1.2.16 java-archive
    …
    util-linux 2.36.1-8+deb11u1 deb
    wget 1.21-1+deb11u1 deb
    zlib1g 1:1.2.11.dfsg-2+deb11u1 deb
    zstd-jni 1.5.0-4 java-archive
    zstd-proxy 4.4.8 java-archive

    When using the -o flat to set the output to spdx-json format, it will produce a document like:

    $ syft -o spdx-json neo4j:latest
    ✔ Parsed image
    ✔ Cataloged packages [376 packages]
    {
    “SPDXID”: “SPDXRef-DOCUMENT”,
    “name”: “neo4j-latest”,
    “spdxVersion”: “SPDX-2.2”,
    “creationInfo”: {
    “created”: “2022-06-23T10:09:26.751733Z”,
    “creators”: [
    “Organization: Anchore, Inc”,
    “Tool: syft-0.48.1”
    ],
    “licenseListVersion”: “3.17”
    },
    …
    “packages”: [
    {
    “SPDXID”: “SPDXRef-fd9f083cc189cf0c”,
    “name”: “CodePointIM”,
    “licenseConcluded”: “NONE”,
    “checksums”: [
    {
    “algorithm”: “SHA1”,
    “checksumValue”: “50a6f2c46702b14cb129aac653d9abfcdc324363”
    }
    ],
    “downloadLocation”: “NOASSERTION”,
    “externalRefs”: [
    {
    “referenceCategory”: “SECURITY”,
    “referenceLocator”: “cpe:2.3:a:oracle-corporation:CodePointIM:11.0.15:*:*:*:*:*:*:*”,
    “referenceType”: “cpe23Type”
    },
    …
    {
    “referenceCategory”: “PACKAGE_MANAGER”,
    “referenceLocator”: “pkg:maven/CodePointIM/CodePointIM@11.0.15”,
    “referenceType”: “purl”
    }
    ],
    “filesAnalyzed”: true,
    “licenseDeclared”: “NONE”,
    “sourceInfo”: “acquired package info from installed java archive: /usr/local/openjdk-11/demo/jfc/CodePointIM/CodePointIM.jar”,
    “versionInfo”: “11.0.15”
    },
    {
    “SPDXID”: “SPDXRef-80979ce84b1617b2”,
    “name”: “FastInfoset”,
    “licenseConcluded”: “NONE”,
    …
    },
    …
    ],
    “files”: [
    {
    “SPDXID”: “SPDXRef-9e950849d3fbc974”,
    “comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
    “licenseConcluded”: “NOASSERTION”,
    “fileName”: “/bin/bash”
    },
    {
    “SPDXID”: “SPDXRef-d1fd1bc48eedeaba”,
    “comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
    “licenseConcluded”: “NOASSERTION”,
    “fileName”: “/bin/cat”
    },
    …
    ],
    “relationships”: [
    {
    “spdxElementId”: “SPDXRef-a124711c55c5b5ec”,
    “relationshipType”: “CONTAINS”,
    “relatedSpdxElement”: “SPDXRef-9f73084aac22b0b3”
    },
    {
    “spdxElementId”: “SPDXRef-a124711c55c5b5ec”,
    “relationshipType”: “CONTAINS”,
    “relatedSpdxElement”: “SPDXRef-23989aa2a193ea3d”
    },
    …
    ]
    }

    This not only includes the packages but also the files in the image, relationships between the elements, licensing information and more.

    cyclonedx/bom

    The Node.js package cyclonedx/bom allows you to generate an SBOM from a Node project in CycloneDX format. An example output when generating the SBOM from github.com/fastify/fastify looks like:

    $ cyclonedx-bom
    $ cat bom.xml
    <?xml version=”1.0″ encoding=”utf-8″?>
    <bom xmlns=”http://cyclonedx.org/schema/bom/1.3″ serialNumber=”urn:uuid:be53de33-6897-49ca-855d-926383866c21″ version=”1″>
    <metadata>
    <timestamp>2022-06-23T10:03:17.018Z</timestamp>
    <tools>
    <tool>
    <vendor>CycloneDX</vendor>
    <name>Node.js module</name>
    <version>3.10.1</version>
    </tool>
    </tools>
    <component type=”library” bom-ref=”pkg:npm/fastify@4.1.0″>
    <author>Matteo Collina</author>
    <name>fastify</name>
    <version>4.1.0</version>
    <description>
    <![CDATA[Fast and low overhead web framework, for Node.js]]>
    </description>
    …
    </component>
    </metadata>
    <components>
    <component type=”library” bom-ref=”pkg:npm/%40fastify/ajv-compiler@3.1.0″>
    <author>Manuel Spigolon</author>
    <group>@fastify</group>
    <name>ajv-compiler</name>
    <version>3.1.0</version>
    <description>
    <![CDATA[Build and manage the AJV instances for the fastify framework]]>
    </description>
    <licenses>
    <license>
    <id>MIT</id>
    </license>
    </licenses>
    <purl>pkg:npm/%40fastify/ajv-compiler@3.1.0</purl>
    <externalReferences>
    <reference type=”website”>
    <url>https://github.com/fastify/ajv-compiler#readme</url>
    </reference>
    <reference type=”issue-tracker”>
    <url>https://github.com/fastify/ajv-compiler/issues</url>
    </reference>
    <reference type=”vcs”>
    <url>git+https://github.com/fastify/ajv-compiler.git</url>
    </reference>
    </externalReferences>
    </component>
    …
    </components>
    <dependencies>
    <dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/>
    <dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/>
    <dependency ref=”pkg:npm/require-from-string@2.0.2″/>
    <dependency ref=”pkg:npm/punycode@2.1.1″/>
    <dependency ref=”pkg:npm/uri-js@4.4.1″>
    <dependency ref=”pkg:npm/punycode@2.1.1″/>
    </dependency>
    <dependency ref=”pkg:npm/ajv@8.11.0″>
    <dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/>
    <dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/>
    <dependency ref=”pkg:npm/require-from-string@2.0.2″/>
    <dependency ref=”pkg:npm/uri-js@4.4.1″/>
    </dependency>
    …
    </dependencies>
    </bom>

    snyk2spdx

    Snyk’s snyk2spdx tool leverages Snyk’s open source API to create an SBOM from your code repositories. Unfortunately, at the time of writing, this repository is outdated and unmaintained.

    Other Tools

    There are also a number of online tools that allow importing different formats or manually adding components to the SBOM definition and then downloading it. The NTIA also published the “How-To Guide for SBOM Generation“, a collection of simple instructions and guidance on how to generate an SBOM. It is interesting that the guide includes the concept of “completeness assertion” for cases where the dependencies of some components are missing.

    Vendor-Provided or Guessed-BOM?

    Ideally, the vendor of a product should tell us every component and provide it in a digitally signed document to prevent tampering or modifications. But we are still far from this holy grail, and there aren’t many vendors producing and providing this information. It’s a complex process involving multiple tools and pieces, and there are multiple standards for SBOM distribution.
    In an ideal world, every vendor would provide a 100% accurate, comprehensive, digitally-signed bill of materials in a common standard. But in the real world, we usually need scanning tools that can produce a ‘guessed’ bill of materials. This is harder, as many components are opaque and it is difficult to discover the dependencies or libraries used during the build.

    Still, scanning is necessary, as the SBOM from the vendor might be wrong. The vendor’s build process might be compromised, so some components might be intentionally omitted from their SBOM, which brings us to the following question: Can the SBOM be wrong or inaccurate?

    Yes. The quality of an SBOM depends on the quality and automation of the process that builds the SBOM.

    It is easy to produce the root level (like the version and details of the software you are directly building) and the first level of dependencies (packages and third-party libraries). It becomes more difficult to do so for transitive dependencies and even harder as you navigate deeper in the tree. Many components might not provide their own SBOM and detecting dependencies can be complex or just plain impossible, like in statically linked binaries with stripped information.

    Even with a perfect toolchain and perfect SBOM information during the build phase, an attacker could tamper with the contents of the SBOM (i.e., modify the companion file or artifact at rest) to hide the fact that it contains vulnerable or malicious components. A consumer would then retrieve the modified version of the SBOM and miss these dangerous components.
    A common, recommended practice is adding a digital signature to the SBOM artifact to make sure the consumer can verify its authenticity and integrity.

    Even worse, it is possible that an attacker could compromise the build pipeline itself and modify the process of creating the SBOM, which would result in a digitally signed but altered list of components.

    From a scanning tool perspective, a software component is usually a black box, or the amount of information that can be obtained from analysis might be quite limited, as most of it (like pom.xml or go.mod files) is available during a build but removed in the final deliverable.

    An appropriate simile would be analyzing food in a laboratory versus having the list of ingredients from the producer. Analysis or scanning would produce quantitative data (what is observed in the box) versus the provided SBOM which can contain qualitative data and that can be lost or invisible to an analysis.

    To minimize the risks of poor quality SBOMs or attacks, it is recommended that organizations use scanning solutions even in the presence of vendor-provided SBOMs.

    SBOMs and Vulnerabilities

    A vulnerability is a weakness or flaw that an attacker can exploit to bypass security boundaries, get access to a system and more. They are a typical way to attack or compromise the software supply chain.

    To find vulnerabilities in a piece of software (or in a running host, a container image, etc.), you need something that matches “known” vulnerabilities with the set of components in your software. This is called vulnerability scanning. And it’s where the SBOM comes into play, as it contains a comprehensive list of packages and versions composing your software.

    Then, another big question arises: Where do the known vulnerabilities come from? (Note that vulnerabilities need to be known in advance, you cannot detect an unknown flaw.) Researchers and hackers discover them and they end up in vulnerability databases that can be consumed by humans or computers. There are two main sources for vulnerabilities: Vendors and independent providers.

    Vendors can provide feeds for vulnerabilities in their products, like major Linux distributions or package repositories like Go, npm, etc. Vendors have good context around how the vulnerability impacts the product. However, they might also be biased in regard to severity.

    Independent providers like NIST, Mitre, the Open Source Vulnerabilities Database and commercial offerings like Snyk and VulnDB collect, analyze and provide information for vulnerabilities. The drawback is the score is objective, without a specific context of how the vulnerability might apply to different products. In some cases, vulnerabilities might not even impact a vendor-specific product version because it is forked or the patch is backported.

    Consuming vulnerability feeds can be challenging because different formats and standards exist for vulnerability information exchange, like:

    ● Red Hat OVAL – An XML format used for Red Hat Enterprise Linux, Openshift, and other Red Hat products and also available for Ubuntu.
    ● Different JSON feeds like the Debian Security Tracker.
    ● APIs like OSV allow querying for specific open source package versions.
    ● Security advisories meant for humans but not for automated processing, like Gentoo security.
    ● NVD CVE JSON v5.0, an attempt to create a standard CVE format.
    ● Common Security Advisory Framework (CSAF) – Standardized automated disclosure of cybersecurity vulnerability issues.
    ● Vulnerability Exploitability eXchange (VEX), which has been implemented as a profile of CSAF.

    VEX is interesting, as it allows vendors to provide a kind of ‘negative’ security advisory that says, for example, that a certain vulnerability does not apply to a component because the submodule in the package is not even used in the product.

    Another source that can help prioritize vulnerabilities is the CISA’s Known Exploited Vulnerabilities catalog (KEV), an updated list of vulnerabilities with assigned CVE ID, reliable evidence of being actively exploited in the wild and clear remediation (such as a vendor update).

    The following diagram describes the full vulnerability management flow:

    A typical flow is comprised of a scanning tool that is capable of creating an SBOM by analyzing a container image, host or workload, or directly by consuming a pre-computed SBOM (or both!). The scanning tool then matches known vulnerabilities from different sources (usually the vendor-provided sources for the corresponding Linux distribution, plus generic sources like NVD to report the list of vulnerabilities impacting the software.

    You can see an example of matching the Kubernetes SBOM (which is publicly available for each version) with known vulnerabilities from OSV using the spdx-to-osv tool.

    The list of detected vulnerabilities can be curated and prioritized with additional information, like VEX (not exploitable vulnerabilities) from the vendor, KEV list or risk spotlight information from Sysdig, which can detect the packages effectively loaded during the execution of the workload. This filters out the packages that are inside a container image but never executed, so they are not exploitable.

    Pitfalls

    Even though there is a lot of buzz around supply chain security and an ever-growing set of tools and products, many of these tools generate SBOMs by analyzing the components and guessing the dependencies.

    The optimal approach to generating an SBOM on every upstream component still requires tailor-made solutions for most cases. This translates into incomplete or inaccurate SBOMs, not to mention the different existing formats (CycloneDX, SPDX, SWID) and lack of a standardized distribution mechanism, making wider consumption of SBOMs pretty difficult.

    Another problem to consider is that the limitations in the SBOM propagate to vulnerability scanners. For example, a missing package can result in a false negative (an existing vulnerability not being reported) and applying a patch on a custom package version can result in a false positive. In general, any package customization which doesn’t result in a version reflected in vulnerability databases might cause a false positive/false negative issue. And there is no single provider for vulnerability information, nor a single exchange standard. Ideally, every vendor would provide their own source of security advisories, and VEX to allow flawless identification of the existing weaknesses.

    Conclusion

    An SBOM is a key element in securing the software supply chain and fundamental for vulnerability matching and management. It is becoming more important as software consumers and governments are raising the collective bar on security requirements and software quality for their providers.

    At the time of writing, there are still different competing standards, a plethora of tools and a lot of uncertainty; most of the actors are still struggling to get there. But the general consensus is that we need to secure the supply chain, converge on common standards, and make the SBOM an essential part of the build process.

    An interesting initiative to follow up to start securing the supply chain is the SLSA framework, which introduces different levels of maturity in the software supply chain, so you can start from nothing and progressively implement different mechanisms to be as resilient as possible, at any link in the chain.

  • To Prevent Supply Chain Attacks, Build Secure Code

    To Prevent Supply Chain Attacks, Build Secure Code

    More than a year after the massive SolarWinds cyberattack, targeted companies continue to feel its ramifications in both reputation and financial cost. Moreover, the global software supply chain remains vulnerable to severe attacks, whether from a hostile nation-state like Russia–now increasingly in the cybersecurity spotlight due to fears of retaliation due to U.S. sanctions–or from any other cybercriminal party. 

    As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, which could allow the persistent presence of malicious actors on a seemingly infinite number of networks; nor do we know when the next attack will happen with potentially more dire consequences. For example, six months after the discovery of the Log4j vulnerability and its associated patches, we know that networks and products all over the world remain unpatched, vulnerable and exploitable in all sorts of companies both big and small.

    This must change. And that change must start from the inside out; meaning programmers, developers and DevOps teams should start building code more securely in the first place. That also means that those who use cloud services, third-party black box software or the services of hub companies, whose networks connect both suppliers and customers, should better understand how code development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce the number of attacks.

    There are signs that the industry is moving in this much-needed direction—or that there are at least more discussions about it. The White House recently hosted meetings with technology experts focused on this very topic. And this spring, the SEC announced that it may begin requiring some companies to report cyberattacks within four days and also provide details about their cybersecurity posture. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices for coding protocols. But regardless of eventual, still-hypothetical regulation, developers—and cybersecurity professionals at hub companies—should give serious thought to the process they use to securely build their products. 

    Beyond Open Source Code

    Of course, an oft-recommended solution is to move to open source software (OSS). Although open source code is still vulnerable to attacks, the processes and practices involved in creating OSS code are transparent, which goes a long way toward crippling the ability of bad actors to conceal themselves. But such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.

    However, there are other steps that could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making gray and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could find and access. Ideally, developers could then also remedy or repair these vulnerabilities. Also, assessing security at every step of the development process could give crucial insights into vulnerabilities before they are discovered in the wild by malicious actors.

    Code-Signing and Scanning Innovations

    Implementing other methods to spot security flaws in code, including in open source code, would also help. Using innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure life cycle and implementing security protocols for merging and accessing the product code; this could prevent cyberattacks from occurring as a result of a faulty (or nonexistent) SDLC process—the same way an electrical engineer couldn’t design a building electric plan without formal training and certification and participating in regular continuing education and recertification. 

    CISOs Need to Be Proactive

    CISOs and IT professionals also have an active role to play. They need to evaluate the security of their products’ underlying code , taking full advantage of the software bill of materials (SBOM), which lists all components of software (and that could soon be required by law) but that is only one side of it. This needs to be coupled with measures like code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities in libraries and frameworks. And it is increasingly important to make sure that contracts with software service providers specify they are adhering to secure development practices. 

    With the world on high alert and the private sector especially vulnerable to state-sponsored cyberattacks, there has never been a better time to focus on building more secure code. This does not mean that all of the other aspects of cybersecurity—including  threat intelligence, incident response plans and hiring and retaining talented professionals—will be any less important. But if the code underlying the software can itself become more secure, these attacks could become fewer in number and their damage less far-reaching. 

  • Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

    Scribe Security Unveils Pair of Tools to Secure Software Supply Chains

    Scribe Security today unveiled a Scribe Integrity tool that scans software artifacts to make sure they comply with IT organizations’ security policies before they are integrated into an application.

    The Scribe Integrity tool authenticates open source and proprietary source code before it is uploaded into a build. It assumes that all artifacts are “guilty” until they can prove their innocence, said Rubi Arbel, CEO of Scribe Security. That approach makes it possible to ensure the integrity of the overall software supply chain is maintained in a way that doesn’t adversely impact the productivity of developers, he added.

    In addition, the company launched GitGat, an open source policy-as-code tool based on Open Policy Agent (OPA) agent software that enables DevOps teams to periodically run reports that surface insights into the security posture of code residing in GitHub repositories.

    Arbel said that, in time, GitGat’s reach will be extended to add support for additional continuous integration/continuous delivery (CI/CD) platforms.

    The first release of Scribe Integrity addresses Node.js code and the npm package manager with support for additional types of code planned.

    The Scribe Integrity tool also identifies all dependencies to enable DevOps teams to generate an accurate software bill of materials (SBOM) as each software artifact is included in the application, he noted. That’s critical because it enables developers, IT operations and cybersecurity teams to simultaneously see what artifacts, including containers, make up an application, noted Arbel. In the future, the company plans to make available a Scribe Hub that will make it easier to share insights into those software artifacts, he added.

    A series of high-profile security breaches clearly demonstrated cybercriminals’ skill at injecting malware into software artifacts and compromise any application that incorporates that artifact into an application. That malware can then be activated at some later date to potentially compromise any number of downstream applications.

    Those incidents resulted in a greater appreciation for DevSecOps best practices to maintain the integrity of software supply chains. The issue that DevOps teams are trying to address is how to build more secure applications without slowing down the rate at which those applications are built and deployed. As such, DevOps teams are adding tools to the application development process that make it easier for developers to scan code before it is included in an application and verify the integrity of any software component that becomes part of a DevOps workflow.

    It’s unknown how long it may be before the adoption of DevSecOps best practices has a meaningful impact on application security. However, waiting to focus on security until after an application has been deployed is way too late. Cybercriminals today can discover flaws and misconfigurations in applications in a matter of minutes. As more applications are deployed, developers can find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building applications that are secure from the ground up is clearly required.

  • Survey Surfaces Raft of Application Security Issues

    Survey Surfaces Raft of Application Security Issues

    A global survey from ReversingLabs found 87% of respondents agreed that software tampering has become a more frequently-used cybersecurity attack, but only 37% said they have any means to detect it.

    The survey, which polled 300 IT and security professionals, was conducted by Dimensional Research on behalf of ReversingLabs, a provider of a platform for analyzing any file, binary or object. Despite software tampering’s frequency, only 7% of survey respondents said they could detect software tampering at each phase of the software development life cycle.

    Just as troubling, only slightly more than half (51%) reported being able to protect their software supply chain with only a third being able to actually check for tampering once an application is final and deployed, the survey found.

    Overall, more than half of respondents (54%) said their organization knowingly released software with potential security risks. Nearly every respondent (98%) also acknowledged that reliance on third-party software use, including open source software, increases security risks.

    On the plus side, more than three-quarters of respondents (77%) said they appreciated the value of a software bill of materials (SBOM) that makes it possible to ascertain what software artifacts are being employed within an application. However, only 27% of respondents said their organization currently generates and reviews SBOMs. A full 90% said they are finding it increasingly difficult to create and review SBOMs. Nearly half of the survey respondents reported that SBOM processes today involved manual steps.

    Other SBOM hurdles respondents cited included lack of expertise (44%) and inadequate staffing to review and analyze SBOMs (44%).

    ReversingLabs CEO Mario Vuksan said that while it’s still early days as far as SBOM capabilities are concerned, a series of high-profile zero-day vulnerabilities has forced the issue into the spotlight. Organizations are now spending months looking for every possible instance of newly discovered vulnerabilities because no one is quite sure what application components are running across an extended enterprise, he noted.

    However, as DevSecOps best practices continue to evolve and mature, it’s also clear that SBOMs will play a critical role in securing software supply chains, Vuksan added. The challenge is that in the age of microservices, application environments are now much more dynamic as components are ripped and replaced with greater frequency, he added.

    SBOMs, of course, are just one element of what will be required to secure a software supply chain. Many organizations are now reviewing their software development processes and uncovering uncomfortable truths about how software is currently built and deployed. The ultimate goal is not to slow down the rate at which software is developed but to make sure there are guardrails in place that prevent insecure software from being deployed in the first place. Far too many developers today still view cybersecurity reviews as tasks to be avoided in the name of meeting an application deployment deadline.

    Hopefully, that won’t continue to be the case as more responsibility and accountability for applications security shifts left toward developers and DevOps teams. In the meantime, however, when it comes to application security, it’s apparent there’s still much room for improvement.

  • The Risks of Shadow Code

    The Risks of Shadow Code

    As the economy struggles to recover after the last two years of the COVID-19 pandemic, we have all learned a thing or two about supply chains—and what happens when they break down. But many people do not realize that modern websites also have digital supply chains, third-party ones that can be compromised in myriad ways. And just like the disruption of the physical supply chain affects things like pricing, availability and inventory, digital supply chains found on today’s websites play a big role in critical areas like site performance, customer experience and overall analytics. As a result, businesses today need to be aware of how the digital supply chain can introduce significant risk, especially when third parties do not adhere to their own set of stringent standards around security and compliance.

    According to a recent study by Source Defense, organizations that collect and use sensitive data—such as health care, finance, travel and online retailers—need to strengthen their focus on third-party risk management. As a result of mandates like GDPR and PCS DSS, these companies are now bound by compliance requirements to ensure their client-side threats are avoided and/or mitigated. This effort means recognizing more than just how to protect private data—it means understanding the properties of malicious code known as “shadow code” on modern websites and how it generates risk from dynamic and unpredictable scripts. Companies dealing in data today need to be aware of the different ways shadow code can affect their security, as well as the productivity and integrity of their DevOps teams.

    Third-Party Scripts and Shadow Code

    Shadow code refers to code that is baked into an application without proper vetting by the website’s IT department. This malicious code thrives in the cloud landscape, primarily because it allows for ease of deployment through CI/CD automation.

    When a web page calls in a third-party script, it loads directly into the browser from a remote server, which means general security controls such as firewalls and network monitoring tools are bypassed. And if one of these scripts has been compromised by a bad actor, shadow code can be embedded within. Sometimes these scripts include open source software that hasn’t been tested well—or at all. Other times, the code may be pulled from another layer of the organization where malicious code is hiding.

    Shadow code presents an array of threat opportunities, including the ability to mount an attack through digital supply chain partners. When these compromised scripts are used to steal data, redirect web traffic,or any other malicious activity, a clear path is essentially created into thousands of different websites, in almost every industry that collects data or deals in digital transactions. When a third-party script with shadow code enters a system, it gains the ability to:

    • Record keystrokes
    • Redirect visitors to malicious websites
    • Monitor clicks and track website activity
    • Change content on websites, including images and text
    • Steal credentials, such as personal logins and social security numbers

    As we know, these digital activities can lead to big consequences, like data breaches, fraud, theft, compliance violations, loss of reputation and hefty fines. Although code reviews can provide some software quality assurance, the process is not effective against shadow code, mostly because these scripts are constantly altered by third-parties. And when the threat is underestimated and unattended, these malicious scripts have the potential to permeate every area of a company’s web property.

    Because the benefits of using these types of third-party scripts are considerable, it can be hard to find a modern enterprise or agency that does not rely on at least a few to run web applications. In fact, many enterprises and government agencies today are running third-party scripts on every page of their sites. Even though these organizations are technically not responsible for this harmful code, regulators can (and do) hold web property owners accountable for any digital maleficence on their sites.

    DevOps Teams and Shadow Code

    Websites can provide rich experiences to visitors largely because developers use client-side JavaScript to improve the look and feel of these digital properties—all without the need for ongoing maintenance. Today, DevOps professionals can access vast libraries of these free and low-cost scripts from many different sources, such as allied coder groups, open source organizations, social media companies, web analytics firms, content delivery networks and more.

    But the reality is, code libraries accessed by DevOps teams are not always secure or trustworthy. Considering these packages often contain code from fourth and fifth parties, DevOps folks face the unavoidable possibility of tainted code—hard to identify and dangerous to use. In fact, the Source Defense report revealed that one in four scripts represented fourth- or fifth-party code, on average. Because developers tend to focus on keeping their code updated and as capable as possible, they often pull from the dynamic library from their repository. If there is a CI/CD process happening, DevOps teams will pull their library from that point. This is where shadow code introduces new vulnerabilities for developers.

    Shadow code also jeopardizes the integrity of DevOps work. Most developers take pride in what they do and are not interested in creating unsecure or low-quality code—not purposefully, anyway. And given that speed, productivity and constant innovation are all business goals for DevOps teams, it’s important to recognize how problematic shadow code can be for those in the business of building secure and high-quality software.

  • Blast Radius of GitHub Breach Major Security Concern

    Blast Radius of GitHub Breach Major Security Concern

    The extent to which software supply chains may be compromised in the wake of a security breach disclosed by GitHub may include thousands of organizations.

    GitHub has revealed that unauthorized parties compromised OAuth user tokens maintained by Heroku, an arm of Salesforce that provides a platform-as-a-service (PaaS) environment, and Travis CI, a provider of a continuous integration/continuous delivery (CI/CD) platform. GitHub has since disconnected the third-party applications that were employing those tokens to access repositories but how much any code might have been exfiltrated or, worse yet, modified may not be known for weeks.

    “There’s a lot of directions this could take,” said Mitch Ashley, principal researcher for Techstrong Research, an arm of Techstrong Group, which owns devopsy.kinsta.cloud. “This is an attack against an authentication mechanism.”

    In fact, the full extent of the blast radius of the breach may never be known unless every organization employing Heroku or Travis CI platforms discloses whether their software supply chains were breached. GitHub has also yet to provide any timeline for the extent of the breach, so no one affected yet knows how far-reaching an investigation should be launched or how long it could take to discover malicious code that may have been injected into applications, noted Brian Soby, CTO at AppOmni, a provider of a platform that provides visibility into platform configurations.

    “We don’t know yet when this occurred,” he said. “This could have a big blast radius.”

    In the meantime, the GitHub disclosure will only intensify security reviews of software supply chains, which have begun in earnest in the wake of a series of high-profile breaches that started with an incident involving an IT service management platform provided by SolarWinds.

    In the case of the latest GitHub breach, security professionals are surmising that developers hard-coded tokens into applications accessing GitHub to make it easier to access repositories. “Developers are lazy,” said Demi Ben-Ari, CTO for Panorays, a provider of a platform for evaluating third-party security risks. “They like to take shortcuts.”

    Some organizations in the wake of the attack may move to distribute source code across repositories from multiple vendors as part of any effort to better secure their intellectual property, noted Ben-Ari.

    Organizations also may decide to rely on code repositories that are not accessed via the cloud. However, given the need to integrate disparate services across a software supply chain, there is no guarantee that an organization with a repository running in an on-premises IT environment wouldn’t be affected by a similar attack.

    On the plus side, as more organizations become aware of the threat vector employed to compromise the GitHub repositories, the level of awareness for implementing best DevSecOps practices should increase. The challenge, of course, remains bridging the technical and cultural divides that often result in developers not following best security practices when building and deploying applications. However, as the number of incidents continues to mount, more organizations are beginning to appreciate just how easy it is for the code they are relying on to engage customers and suppliers to be tampered with or outright stolen.

  • Survey Sees Little Progress on Securing Software Supply Chains

    Survey Sees Little Progress on Securing Software Supply Chains

    A survey of 1,750 IT security decision-makers published today found that, despite a series of high-profile cybersecurity breaches, nearly two-thirds (62%) of respondents have done nothing to secure their software supply chain. A full 64% conceded that an attack against their software development environment could not be stopped. And nearly three-fourths (71%) of respondents admitted their organization suffered a successful software supply chain-related attack that resulted in data loss or compromise of an asset, while 85% acknowledged a software bill of materials would also reduce the risk of compromise to a software supply chain.

    The survey, conducted by the market research firm Vanson Bourne on behalf of CyberArk, a provider of a privileged access management (PAM) platform, also found that 87% of respondents stored secrets in multiple places across DevOps environments, while 80% conceded developers typically have more privileges than necessary for their roles. Only 3% of respondents said their organization has a centralized secrets management platform to manage credentials used by applications.

    Organizations are also struggling to keep pace with the number of digital identities that have access to IT services. The average staff member has access to more than 30 applications and accounts, the survey found. However, 68% also reported non-humans or bots have access to sensitive data and assets, with machine identities now outnumbering human identities by a factor of 45, on average, the survey found. Less than half (48%) of respondents have any type of identity security controls in place for their business-critical applications.

    Even the threat of ransomware doesn’t seem to be having much of an impact. More than 70% of respondents said their organization has experienced, on average, two ransomware attacks in the past year.

    Brandon Traffanstedt, senior director for the global technology office at CyberArk, said it’s apparent organizations are accruing a significant amount of security debt that is not being proactively addressed. In fact, more than two-thirds of respondents (69%) said their organization has prioritized maintaining business operations over ensuring robust cybersecurity in the last 12 months. A full 99% of respondents said their organization had fast-tracked the adoption of at least one business/IT initiative over the last 12 months.

    In general, hybrid working (86%), the introduction of new digital services for customers or citizens (84%) and increased outsourcing (84%) are identified as the activities that are introducing the greatest risks. Specifically, the survey found credential access (40%) was the number one area of risk, followed by defense evasion (31%), execution (31%), initial access (29%) and privilege escalation (27%).

    Real-time monitoring and analysis to audit all privileged session activity; least privilege security/zero-trust principles on infrastructure that run business-critical applications and processes to isolate business-critical applications from internet-connected devices to restrict lateral movement are tied at 54% for the top three security initiatives organizations are planning to implement. The top three strategic zero-trust initiatives are workload security (52%), identity security (50%) and data security (45%), the survey found.

    Ultimately, the only way to address the current level of security debt organizations are incurring is by embedding functionality into DevOps workflows that automatically apply security policies and teaching developers to build more secure applications, said Traffanstedt. The former approach, however, may have a bigger impact more quickly, given the current level of cybersecurity expertise that currently exists in the developer community.

  • Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Researchers Find Privilege Escalation Vulnerability in GitHub Repos

    Legit Security today revealed that it discovered a privilege escalation vulnerability in GitHub repositories that has since been remediated.

    Liav Caspi, Legit Security CTO, said the company worked with GitHub to remediate the issue prior to disclosure. Legit Security researchers reported they found hundreds of GitHub instances rated with over 1,000 stars each that could be subject to the vulnerability.

    Caspi said the company also reached out directly to most of those affected sites, including an instance of GitHub that is used to develop the open source Nginx web server that is employed across hundreds of millions of websites.

    Cybercriminals could exploit a vulnerable build script to modify code or built artifacts that would result in software being shipped with code controlled by some other entity. The vulnerability could also enable access to sensitive secrets, such as keys, that are used to access cloud services or simply create a malicious pull request.

    Legit Security researchers employed a set of risk assessment tools that are part of a larger software-as-a-service (SaaS) platform that enables them to apply security policies across their entire software development life cycle. Earlier this year, the company made available a free Rapid Risk Assessment tool to provide organizations with more insights into their software supply chains. Security research findings, along with other security best practices, are embedded within the policies that can be enforced via the Legit Security platform.

    In the wake of a series of high-profile breaches, there is now more focus on the security of software supply chains than ever. Gartner estimated that 45% of organizations worldwide will have experienced attacks on their software supply chains by 2025, a threefold increase from 2021.

    Despite those concerns, however, the rate at which new applications are being deployed and updated doesn’t appear to be slowing. Organizations are too dependent on software to encourage customers to slow down the development and deployment rate of applications. It will, however, take years for organizations to properly train developers to correctly employ security tools within their application development processes, otherwise known as DevSecOps best practices, to reduce the number of vulnerabilities that now routinely manifest themselves in production environments. The only practical alternative is to embed more tools that automatically discover vulnerabilities in code during the application development process.

    Regardless of the DevSecOps approach, the ultimate goal remains to build more secure applications faster. That can only be achieved if there are more guardrails in place that prevent developers from inadvertently introducing vulnerabilities into an application. The more frequently applications are updated, the more likely it is that a vulnerability will be introduced. Each time those vulnerabilities are discovered after an application is deployed in a production environment, the more expensive they are to remediate. As the volume of vulnerabilities increases, it’s also only a matter of time before the sheer number of security issues that need to be addressed overwhelms both developers and security operations teams alike.

    Application security, of course, has not always received the attention it deserves, but demands for increased application security can no longer be ignored.

  • Fixing Spring4Shell Starts With Software Supply Chain Management

    Fixing Spring4Shell Starts With Software Supply Chain Management

    Spring4Shell is the latest call to action for radically improved software supply chain integrity. While Spring4Shell investigations continue, one conclusion is indisputable: We must holistically rethink the way we continuously inventory and manage the complex landscape of interrelated software and its sources.

    Whether or not Spring4Shell surpasses the breadth of impact of Log4j, there’s still massive potential for severe consequences to software and API security across the open source infrastructure, frameworks and application software stacks.

    That’s because, as we saw with Log4j, this attack could impact most enterprise Java applications globally. It seems the root cause is a vulnerability in the widely used, free, community-developed, open source programming framework Spring Core.

    The Spring framework is the foundation for most enterprise Java applications—as many as 74%, according to some data. Specifically, Spring serves as the foundation for enterprise Java apps so that teams can focus on application-level business logic without being locked into specific deployment environments.

    Spring Core’s ubiquity introduces significant potential for widespread impact due to its use across enterprise software, cloud services, third-party software and service products as well as internally managed software. This is another call-to-action to improve the way we approach software supply chain security and supply chain management. Thankfully, there’s already a place to start.

    Every infrastructure and software team can begin addressing this vulnerability by leveraging resources from The Linux Foundation’s Software Bill Of Materials (SBOM) project. The 2021 initiative included an SBOM readiness survey, a Generating Software Bill Of Materials training course and an SBOM generator tool based on the SPDX standard (ISO/IEC 5962:2021).

    The Linux Foundation’s SBOM contributions provided all of us a head start to begin addressing issues with software supply chain management. With widespread adoption, SBOM equips software projects and users to assess and address Spring4Shell as well as any other as-yet-unknown vulnerabilities and prepare us for what is undoubtedly a season of high-impact infrastructure software vulnerabilities.

    For more Spring4Shell resources, please visit: https://www.contrastsecurity.com/security-influencers/new-spring4shell-vulnerability-confirmed-what-it-is-and-how-to-be-prepared

  • Secure Software Summit: Behold the SBOM

    Secure Software Summit: Behold the SBOM

    With supply chain security becoming more of a focus, the SBOM is now viewed as a critical element in shoring up supply chain security. SBOM stands for software bill of materials. At a very elementary level, an SBOM is a list of ingredients. Think about how every food product in the supermarket lists ingredients so, for example, people who are allergic to nuts can avoid nuts. An SBOM does the same thing for software applications. 

    If you want to do business with the U.S. government, SBOMs are no longer optional. Executive order 14028 requires an SBOM for all U.S. federal software procurements. Why the push for SBOMs now? Software companies generally do not list all the components included in the software they produce. Knowing what components are included in applications is essential for proactive vulnerability management. That said, the government mandate for SBOMs only requires a minimal amount of included information—supplier name, the component name and version, dependency relationships, time stamps for versions or modification and information about who authored the SBOM itself. 

    What to Look For in an SBOM

    This minimum required data yields minimal benefit for cybersecurity risk reduction and vulnerability management. SBOMs can actually include many other types of information. What information should you include in SBOMs for software applications produced, purchased or consumed by your organization? Here is a list. 

    Authenticity —Authenticity asks and verifies that someone actually created a listed component. Ideally, this requires a digital signature of some sort. Authenticity can be particularly important in the case of nested components where the supplier of an application includes multiple other components, as is common with JavaScript and Java libraries used for common functionalities. 

    Integrity —This addresses whether a component has been tampered with or modified without authorization. An SBOM should include some measure of integrity. Equally important is proving the integrity of the SBOM itself. Just as CheckSum can tell you whether software you are loading matches what the source of that software indicates, integrity checks should allow you to verify that components on an SBOM (and the SBOM itself) are exactly what you are expecting. 

    Services —An inventory of services called by an application is critical. Modern software does not live in a vacuum. It calls out to the Internet to perform all sorts of tasks and communication with other systems. Those services that extend beyond your application are part of the inventory because they can be an indication of vulnerability or indicate a larger problem.

    Vulnerability Remediation Status —Development teams are constantly balancing the need to remediate vulnerabilities against the risk that remediation will break the application. Some open source projects, for example, have a history of not backporting security fixes. The latest version of the project may break applications. Organizations are forced to choose between breaking an application or taking the risk of introducing a high-severity vulnerability that might be exploited. Responsible organizations that opt to keep the older version and not break their software will backport their own fixes. An SBOM should describe these variations and any other vulnerability remediation activity. 

    Inventory of component security advisories —An SBOM should describe security advisories pending against all components. This is likely to be a dynamic list that you will need to automatically update using one of the accepted vulnerability advisory formats (CSAF and CycloneDX, to name two). In fact, this is one of the strengths of SBOMs—they are designed for automation and to act programmatically. 

    Completeness —It is not always possible to ship complete SBOMs, either for technical or intellectual property reasons. An SBOM should indicate whether it is complete and whether it contains a comprehensive inventory of dependencies and services. 

    Pedigree —This information describes the DNA of the SBOM and the original makeup and changelog of each particular component. An SBOM should describe the original component, exactly what changes were made, who committed the changes and why, what the differences were between different versions and what security issues were fixed with each variation and version. 

    Provenance —This relates to the origin of a component or service. It can describe a repository that the component was downloaded from, a country of origin, the name of a software manufacturer or open source project or other information indicating the component or service’s source of origin. 

    License type —License information is relevant for compliance and to ensure that your organization is not consuming or producing software in a manner that violates licensing terms. Moreso than for security and vulnerability, this information is for risk management, compliance enforcement and auditing. 

    Customizing SBOMs to Meet Your Needs

    The SBOM is a flexible and highly adaptable approach that can be easily customized to fit specific use cases. You can design SBOMs to meet the specific needs of your use case, either as a software provider or consumer. You also may need to modify your SBOM fields and data design as your needs evolve. Fortunately, it is rapidly becoming easier to automatically generate SBOMs using software security tools such as software composition analysis (SCA) and interactive application security testing (IAST) solutions. SBOMs can also be created or read automatically at other points during the build life cycle along the continuous integration/continuous deployment (CI/CD) process. Just as you would not buy a box of cereal that did not list the ingredients, in the future you will not want to consume software that does not have a detailed SBOM. What you don’t know about the software you run can hurt you, and SBOMs will be a crucial tool in providing greater transparency and observability into the software supply chain. 

    About Secure Software Summit
    The Secure Software Summit brought together the world’s leading innovators, practitioners and academics of secure software development to share and teach the latest methods and breakthroughs on secure coding and deployment practices. If you are about developing, releasing and securing software, delivering new features fast and building things right from the start, click on the link below to get access to all of the sessions from this summit.

    https://go.shiftleft.io/secure-software-summit-2022-replay