diff --git a/404.html b/404.html index ec4f555..678373e 100644 --- a/404.html +++ b/404.html @@ -15,7 +15,7 @@
- + \ No newline at end of file diff --git a/about-us.html b/about-us.html index 850a37a..68f4211 100644 --- a/about-us.html +++ b/about-us.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

SBOM Everywhere SIG (About us) ​

OSSF SBOM Everywhere SIG ​

Home of the OpenSSF SBOM Everywhere SIG. We're glad you're here!

Get Involved ​

Meeting times ​

  • Every other Tuesday @ 11:05am EST. The invite is available on the OpenSSF Community Calendar.
  • Meeting Minutes can be found in this Google Document. Feel free to add agenda items, please put your name next to items you add.

Motivation ​

  • The initial motivation for the formation of the OSSF SBOM Everywhere SIG is born from OpenSSF's The Open Source Software Security Mobilization Plan. SBOM standardization and consensus from within the open source community is integral to adoption of universal constructs that reveal themselves via the exploration of use cases beyond a compliance check box.

Objective ​

The 3 overarching goals from the White House meeting ​

  • Securing OSS Production: focus on preventing security defects and vulnerabilities in code and open source packages in the first place
  • Improving Vulnerability Discovery & Remediation: improving the process for finding defects and fixing them
  • Shorten Ecosystem Patching Response Time: Shorten the response time for distributing and implementing fixes.

The goals for this group as defined in the mobilization plan ​

  • The requirements needed to build use cases using SBOMs are clearly understood, documented and implemented in current SBOM specifications
  • There are “friction free” open source tools that generate SBOMs that meet these requirements
  • There is readily accessible education, awareness and implementation guidance and 3rd party support

Scope ​

The mobilization plan defines scope as By focusing on tools and advocacy, we can remove the barriers to generation, consumption, and overall adoption of SBOMs everywhere, we can improve the security posture of the entire open source ecosystem: producers, consumers, and maintainers.

Formatting Specifications ​

For the purposes of establishing ubiquity to ensure sustainability for SBOM related tooling, and future solutions for consumption, “supported” formats must be defined. At this time there are two supported formats that will be in scope for the purposes of this group: CycloneDX and SPDX.

Utilization of these specifications would likely be discretionary and interchangeable depending on the use case and SBOM type and the requirements of individual organizations and internal tooling.

This group's interpretation is

  • Use cases
  • Defining types of SBOMs
    • Source
    • Binary analysis
    • Build
    • Deploy Runtime
  • Generation
    • Formats - clearly define expectations
  • Consumption
    • How do we track and encourage the consumption of the artifacts
    • something about tools
  • Adoption (how do we encourage others to create and use SBOMs)
    • Something about producers, consumers, and maintainers
    • Where does the burden lie on accountability and enforcement?
    • something about tools
      • Tools are everywhere, what do we do with this?
    • something about advocacy
  • Attestation?
    • Not part of tooling, this needs to be a policy decision in these conversations, don't worry about the technical details (yet)
    • Where does this fit in? Producers, consumers, ???
    • https://github.com/in-toto/attestation
  • Compliance (regulated industry)

The Federal Government exists at every point of the Software Delivery Lifecycle, hence their minimum requirements are good guides to establish a baseline scope.

SBOM Catalog ​

To provide a better overview of the available tooling and their capabilities, this group maintains an SBOM Catalog which can be found under the following link:

https://ossf.github.io/sbom-everywhere/

If you want to get involved, please see the document here

Prior Work ​

NTIA ​

NTIA's legwork has been a guiding source having done the most comprehensive research to date.

CISA ​

OWASP SCVS ​

Governance ​

The CHARTER.md outlines the scope and governance of our group activities.

- + \ No newline at end of file diff --git a/basics.html b/basics.html index 3860483..fea714e 100644 --- a/basics.html +++ b/basics.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Basics ​

Work in Progress

This site is Work in progress and just a concept.

- + \ No newline at end of file diff --git a/example-integrations.html b/example-integrations.html index efe9f76..afb0a0f 100644 --- a/example-integrations.html +++ b/example-integrations.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Example integrations ​

Work in Progress

This site is Work in progress and just a concept.

- + \ No newline at end of file diff --git a/faq.html b/faq.html index 404bfb3..07784aa 100644 --- a/faq.html +++ b/faq.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Frequently asked questions ​

Work in Progress

This site is Work in progress and just a concept.

- + \ No newline at end of file diff --git a/getting-started.html b/getting-started.html index a957ead..3ada37d 100644 --- a/getting-started.html +++ b/getting-started.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Getting Started ​

Select an SBOM-Generation Phase ​

Depending on the technology stack used, the phase of the software development lifecycle in which an SBOM is generated can significantly affect its quality. The different phases are explained in more detail in the SBOM types. For open-source projects, it is most beneficial to provide a source or a build SBOM, giving the consumer insights into the composition of a project build before it is compiled into an artifact. This provides access to details of the project composition that might otherwise remain hidden. While providing an SBOM based on the analysis of a build artifact can also be useful, such an SBOM can be produced by the user with their preferred tooling.

Choose a Generation Methodology ​

Assuming the goal is to produce a source or build SBOM for a project, it should be decided whether the SBOM generation should be part of the build process (like a plugin added to the build tooling) or if a separate tool should be applied to the repository during the build.

SBOM Generation in the Build Process ​

Adding SBOM generation directly to the build process might produce the best results. The SBOM is based on the build information directly and can therefore represent most of the complexity, such as traversing dependencies or dynamic dependency resolving with variables or version ranges. However, integrating SBOM generation into the build process can complicate changes. Additionally, if the project is composed of several technologies, each requiring its own build tooling and corresponding SBOM plugins, merging the SBOM generation results might be very challenging. Most build plugins only support one of the two SBOM standards, necessitating the choice of one standard or the integration of two SBOM plugins to cover SPDX and CycloneDX separately. This can also lead to additional complexity because these plugins can report different findings for the same project.

In summary, integrating SBOM generation into the build process via plugins might produce the best results but can add a lot of additional complexities. However, only a few or none of these constraints may apply to a project.

SBOM Generation with a Separate Tool ​

There are also tools that can be applied to the sources of a project without relying on a build integration. Tools like Syft, Trivy, or CdxGen can be used in this manner. While they are easier to integrate and operate within a project, they might not produce the best quality SBOM. Depending on the technology stack and build setup, it can be harder to resolve traversing dependencies, versions from version ranges or variables might be incorrect or missing, and license information might be wrong or missing (you can find some test reports here). On the plus side, they are easy to integrate, often support both SBOM standards (SPDX and CycloneDX), and can cover projects using several technologies in the same repository (no merging of SBOM data required).

In summary, generating the SBOM with a separate tool is a good start and can be easier, but the results might be more accurate if derived from the build process. Nevertheless, the results might still be able to meet the requirements of the NTIA minimum elements for an SBOM (US regulations) or the requirements set by the EU CRA (EU regulations).

Select an SBOM Tool ​

To select a tool, check out our tooling catalog.

Integrate into Your Build ​

When integrating an SBOM generator into a project, it is important to ensure that each artifact gets its own SBOM. This is not an issue if the project produces only one artifact. However, if the project is, for example, a monorepository holding several products built for different platforms using diverging dependencies, it is important to provide separate SBOMs for each of them.

Publish with Your Artifacts ​

An SBOM should be published along with its artifacts. It can also be considered to publish an SBOM inside an artifact to make it inseparable from the provided artifact. Further guidance is provided by the SBOM naming document.

- + \ No newline at end of file diff --git a/glossery.html b/glossery.html index 1ed8632..b88e67b 100644 --- a/glossery.html +++ b/glossery.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Glossery ​

Work in Progress

This site is Work in progress and just a concept.

SBOM ​

A Software Bill of Materials (SBOM) is a structured record that identifies the components and their relationships within a software product. It functions like an ingredients list, detailing the various software components and their versions that make up a final software product. This record helps with transparency in the software supply chain, enabling better understanding, management, and ultimately, improved security of the software.

SPDX ​

CycloneDX ​

SWID ​

- + \ No newline at end of file diff --git a/hashmap.json b/hashmap.json index dba55dd..40b00ae 100644 --- a/hashmap.json +++ b/hashmap.json @@ -1 +1 @@ -{"example-integrations.md":"C7TcWRje","basics.md":"BXvVLpB1","faq.md":"DO2Q_wmd","index.md":"Dv0ouDC5","sbom-compliance.md":"D54522cY","sbom-naming.md":"DL__h58T","glossery.md":"BODyUEJc","about-us.md":"TuGxV0Iq","catalog_index.md":"CoaHJ-Hc","sbom-working-groups.md":"CAhZ5XRG","sbom-types.md":"CrReF_oB","getting-started.md":"RGT6aYqW"} +{"getting-started.md":"RGT6aYqW","glossery.md":"BODyUEJc","index.md":"Dv0ouDC5","sbom-types.md":"CrReF_oB","basics.md":"BXvVLpB1","sbom-naming.md":"DL__h58T","about-us.md":"TuGxV0Iq","example-integrations.md":"C7TcWRje","sbom-working-groups.md":"CAhZ5XRG","sbom-compliance.md":"D54522cY","catalog_index.md":"CoaHJ-Hc","faq.md":"DO2Q_wmd"} diff --git a/index.html b/index.html index cef80d5..dbe0ce3 100644 --- a/index.html +++ b/index.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

- + \ No newline at end of file diff --git a/sbom-compliance.html b/sbom-compliance.html index b566569..7877860 100644 --- a/sbom-compliance.html +++ b/sbom-compliance.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

SBOM in compliance ​

EU Cyber Resiliance Act
🇪🇺
​

The European Cyber Resilience Act (CRA) includes requirements for the identification and management of supply chain risks, and the proposed European Cybersecurity Certification Scheme would likely require the use of Software Bill of Materials (SBOM) and secure software development practices. The Cybersecurity Resilience Act lays out specific actions and strategies regarding the responsibility and the means to protect software vulnerabilities, including specifying vulnerability reporting format and requirements, anchored in the form of a SBOM.

2024-03-12

Guide of Introduction of SBOM for Software Management
🇯🇵
​

Japan's Ministry of Economy, Trade and Industry (METI) published a guide to promote SBOM use. Highlighting growing software security concerns, METI targets software suppliers with this guide, which details the benefits and steps for implementing SBOMs. This initiative aims to improve software vulnerability management, enhance development productivity, and bolster overall cybersecurity in Japanese industries.

2023-07-28

Technical Guideline TR-03183
🇩🇪
​

The Technical Guideline TR-03183: Cyber Resilience Requirements for Manufacturers and Products Part 2 Software Bill of Materials (SBOM) provides essential guidance for creating an SBOM. The Technical Guideline TR-03183 aims to provide manufacturers with advance access to the requirements that will be imposed by the future EU Cyber Resilience Act (CRA). While it is recommended (but not obligatory), it serves as a basis for discussion both within the EU and internationally.

2023-07-12

SBOM startersgids
🇳🇱
​

The Dutch National Cyber Security Center (NCSC) has published a SBOM Starter Guide to assist managers involved in their organization's cybersecurity strategy with implementing SBOMs. This guide explores how organizations can establish processes for using SBOMs, create, manage, and share them effectively, and develop strong agreements with vendors. It also dives into how SBOMs can be utilized for vulnerability management and offers additional insights through supporting frameworks.

2023-07-05

The Minimum Elements for a SBOM
🇺🇸
​

The NTIA Minimum Elements for an SBOM requires that SBOMs show, for each software component: supplier, component name, version, any unique identifiers like CPE SWID or PURL, dependency relationship, and the author of this information along with a time/date stamp when it was generated. The minimum elements of an SBOM build on three broad, interrelated areas: Data fields, Operational considerations, and Support for automation. SBOMs must comply with at least one of the following SBOM standards: Software Package Data eXchange (SPDX), CycloneDX, or Software Identification (SWID) tags. The minimum elements of an SBOM will enable basic use cases, such as management of vulnerabilities, software inventory, and licenses.

2021-07-12

White House Executive Order 14028
🇺🇸
​

The White House Executive Order on cybersecurity includes new security requirements for software vendors selling software to the U.S. government. It emphasizes the importance of enhancing software supply chain security through the Software Bill of Materials (SBOM). The Executive Order defines an SBOM as “a formal record containing the details and supply chain relationships of various components used in building software”.

2021-05-12

- + \ No newline at end of file diff --git a/sbom-naming.html b/sbom-naming.html index 6896ca8..05f64d9 100644 --- a/sbom-naming.html +++ b/sbom-naming.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Best Practices for Naming and Directory Conventions for SBOMs (Software Bill of Materials) in Open Source Projects ​

The Software Bill of Materials (SBOM) plays a vital role in providing visibility & transparency into the software supply chain. Using SBOM standards such as CycloneDX and SPDX ensures interoperability, accurate dependency tracking, and efficient vulnerability management. Here are some best practices for naming and directory conventions when creating and managing SBOMs.

Scope ​

This document only covers SBOMs of Type Source and Build as SBOMs of other types are typically not curated by the maintainers of Open Source software but instead by consumers of Open Source software. The audience for this document is open source projects distributing artifacts directly rather than distributing artifacts via an ecosystem such as Maven or NPM.

For Source and Build SBOMs, the contents of the SBOM describing the artifact will only include what is being distributed and will not contain information about prospective uses of the software during or after installation or running of the software. That information is captured in separate SBOM types (ie Deployment, Runtime).

In the context of this document, the “source” is defined as a snapshot of the source code made available to download, such as in a tgz archive.

The “build” is the artifacts that are built by the project and released. These could be tgz archives, but also other artifacts such as rpm, deb, or zip.

This document does not prescribe best practices to specific software ecosystems (Maven, PyPI, etc) which are likely to have specific requirements about how to distribute accompanying metadata alongside software distributions, however this should not preclude the use of all or part of this guidance for this use-case.

There may be instances where a release is also uploaded to an ecosystem. It is not expected that the SBOM generated for the releases would be uploaded to those ecosystems.

Consistent Naming Conventions ​

For SBOMs which are distributed with source tarballs or pre-built binaries as a part of a defined release of the software, the requirements for “release” files is typically a flat list of files without directories (think GitHub or GitLab Release artifacts). To meet these requirements, no directory structures should be used.

Following guidance from SLSA provenance attestations of appending a corresponding extension to the filename of the artifact that is being described. For the CycloneDX and SPDX SBOM standards and their file extension formats the guidance is as follows:

Standard + FormatArtifact FilenameSBOM Filename
CycloneDX JSONartifact-1.0.0.tar.gzartifact-1.0.0.tar.gz.cdx.json
CycloneDX XMLartifact-1.0.0.tar.gzartifact-1.0.0.tar.gz.cdx.xml
SPDX TAG:VALUEartifact-1.0.0.tar.gzartifact-1.0.0.tar.gz.spdx
SPDX JSONartifact-1.0.0.tar.gzartifact-1.0.0.tar.gz.spdx.json
SPDX XMLartifact-1.0.0.tar.gzartifact-1.0.0.tar.gz.spdx.xml
SPDX YAMLartifact-1.0.0.tar.gzartifact-1.0.0.tar.gz.spdx.yml (or .yaml)
SPDX RDF XMLartifact-1.0.0.tar.gzArtifact-1.0.0.tar.gz.spdx.rdf (or .rdf.xml)

The .spdx.* and .cdx.* extensions are sourced from the CycloneDX and SPDX guidance on filename extensions for SBOM documents of the corresponding standard and format.

The JSON format files should be considered a mandatory requirement and are always available. The tool support for JSON documents is considered to be better than the other file format options. If other formats are desired, the JSON SBOM should also be available.

Acknowledgements ​

The following community members helped contribute to this guidance

  • Josh Bressers, Anchore
  • Marius Biebel. hm.edu
  • Ian Dunbar-Hall, Lockheed Martin
  • Maximilian Huber, TNG Technology Consulting
  • Dan Appelquist, Samsung (formerly, Snyk)
  • Seth Larson, Python Software Foundation
- + \ No newline at end of file diff --git a/sbom-types.html b/sbom-types.html index 6fe0860..7e290c0 100644 --- a/sbom-types.html +++ b/sbom-types.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

Types of Software Bill of Material (SBOM) Documents ​

Go to original document.

This document was reviewed and published by CISA. You can find the original document here.

Introduction ​

Today there is a widely-used definition of the minimum content of a Software Bill of Material (SBOM). However, an SBOM may contain different forms of the minimum information sourced from different product artifacts. Given the disparate ways SBOM data can be collected, the results may vary, yet still provide value in different use cases. This document summarizes some common types of SBOMs that tools may create in the industry today, along with the data typically presented for each type of SBOM. An SBOM document may combine information for multiple SBOM types.

Definitions and Discussions ​

The following two tables summarize the different types of SBOMs and the benefits and limitations of each type. This list of SBOM types is not intended to be tightly tied to the software lifecycle. Some SBOM types may be available and useful across multiple lifecycle phases, while others may be available only in one lifecycle phase. Also, the data presented within an SBOM type may vary, depending on the software’s lifecycle phase and industry.

SBOM Type Definition and Composition ​

TypeDefinitionDescription
DesignSBOM of intended design of included components (some of which may not exist) for a new software artifact.Typically derived from a design specification, RFP, or initial concept.
SourceSBOM created directly from the development environment, source files, and included dependencies used to build an product artifact.Typically generated from software composition analysis (SCA) tooling, with manual clarifications.
BuildSBOM generated as part of the process of building the software to create a releasable artifact (e.g., executable or package) from data such as source files, dependencies, built components, build process ephemeral data, and other SBOMs.Typically generated as part of a build process. May consist of integrated intermediate Build and Source SBOMs for a final release artifact SBOM.
AnalyzedSBOM generated through analysis of artifacts (e.g., executables, packages, containers, and virtual machine images) after its build. Such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM.Typically generated through analysis of artifacts by 3rd party tooling.
DeployedSBOM provides an inventory of software that is present on a system. This may be an assembly of other SBOMs that combines analysis of configuration options, and examination of execution behavior in a (potentially simulated) deployment environment.Typically generated by recording the SBOMs and configuration information of artifacts that have been installed on systems.
RuntimeSBOM generated through instrumenting the system running the software, to capture only components present in the system, as well as external call-outs or dynamically loaded components. In some contexts, this may also be referred to as an “Instrumented” or “Dynamic” SBOM.Typically generated from tooling interacting with a system to record the artifacts present in a running environment and/or that have been executed.

Understanding the Benefits and Limitations of SBOM Types ​

TypeBenefitsLimitations
Design- Highlight incompatible components ahead of licensing purchase or acquisition.
- Defines approved or recommended included component list for developer use.		- This may be very difficult to generate.
- Unlikely to identify as much detail as found in other SBOM types.
Source- Provides visibility without access to build process.
- Can facilitate remediation of vulnerabilities at the source.
- Can provide a view into the dependency tree / hierarchy of the included components.		- Can highlight components (which might have vulnerabilities) that never run or are compiled out in deployed code.
- Depending on language/ecosystem, may not include runtime, plugin, or dynamic components, like appserver or platform libraries.
- May require references to other SBOMs for completeness.
Build- Increases confidence that the SBOM representation of the product artifact is correct due to information available during the build and/or Continuous Integration/Continuous Deployment (CI/CD) processes.
- Provides visibility into more components than just source code.
- Increased trust by enabling signing of the SBOM and product artifact by the same build workflow.		- Potentially have to change the build process to generate this SBOM.
- Highly dependent on the build environment in which the build is executed.
- May be difficult to capture indirect and/or runtime dependencies.
- May not contain the correct versions of dynamically linked dependencies (as they may be replaced at runtime depending on language/ecosystem).
Analyzed- Provides visibility without an active development environment, such as legacy firmware artifacts.
- Does not need access to the build process.
- Can help verify SBOM data from other sources.
- May find hidden dependencies missed by other SBOM type creation tools.		- May be prone to omissions, errors, or approximations if the tool is unable to decompose or recognize the software components precisely.
- May depend on heuristics or context-specific risk factors.
Deployed- Highlights software components installed on a system, including other configurations and system components used to run an application.- May require changing install and deploy processes to generate.
- May not accurately reflect the software’s runtime environment, as components may reside in inaccessible code.
Runtime- Provides visibility to understand what is in use when the system is running, including dynamically loaded components and external connections.
- Can include detailed information about whether components are active and what parts are used.		- Requires the system to be analyzed while running, which may require additional overhead.
- Some detailed information may be available only after the system has run for a period of time until the complete functionality has been exercised.

Conclusion ​

These definitions are meant as a starting point for clarifying SBOM types that varying tooling types and methods may create. Different tooling approaches may be required to create the same SBOM type for different kinds of software. This document may evolve as the innovation around SBOMs and their uses may require the addition of more SBOM types. Progress in adopting and refining Vulnerability Exploitability eXchange2 (i.e., VEX), service dependencies, and “SBOM of SBOMs,” among others, may require additional types of SBOMs.

If you would like to learn more about tooling associated with SBOMs, reach out to SBOM@cisa.dhs.gov.

- + \ No newline at end of file diff --git a/sbom-working-groups.html b/sbom-working-groups.html index b31cb4e..53a0ed7 100644 --- a/sbom-working-groups.html +++ b/sbom-working-groups.html @@ -18,7 +18,7 @@
SBOM-Everywhere Wiki

Appearance

SBOM working groups ​

CycloneDX ​

To get in touch with the CycloneDX community you best join the CycloneDX Slak. Further information is provided on the CycloneDX participate page.

SPDX ​

SPDX published their open workstreams in the following Github repository

General meeting
First Thursday of the month @11am ET
​

  • Description: General call with general updates, updates from each Team, and sometimes guest speakers (e.g., talks on how people are using SPDX, GSoC student presentations, etc.)
  • Jitsi meeting
  • Meeting minutes and agendas

Tech Team meetings
Thursday @12am ET
​

Outreach Team meetings
Monday @10am ET
​

Sub-groups for specific topics ​

Security Profile group meetings
Wednesdays @2pm ET
​

  • Description: Regular meeting to discuss representation of software vulnerability metadata in the SPDX specification including vulnerability identifiers, status, mitigations and remediations.
  • Jitsi meeting
  • Meeting minutes and agendas

Implementers group meetings
Wednesdays @11am ET
​

AI and Data Profiles group meetings
Wednesdays @3pm ET
​

Functional Safety Profile group meetings
Friday @12am ET
​

Serialisation Focus Group meetings
Thursday @11am ET
​

  • Description: Regular meeting to discuss the serialisation formats for SPDX, enumerating the use cases for serialisation and determining stakeholder preferences.
  • Jitsi meeting

Software as a Service Profile group meetings
Every other Monday @1pm ET
​

  • Description: Regular meeting to discuss how the SPDX specification can better support and track SAAS use cases.
  • Jitsi meeting

Hardware Profile group meetings
Friday @9am ET
​

  • Description: Regular meeting to discuss how the SPDX specification can extend to support firmware, FPGAs, Open Hardware Boards, SOCs, IP blocks, Cores in physical and virtual environments.
  • Jitsi meeting
  • Meeting minutes and agendas

Operations group meetings
Friday @9:30am ET
​

  • Descriptions: Regular meeting focused on the additional information that an organization may wish to associate with a package, for effective management of these artifacts within business operations.
  • Jitsi meeting
  • Meeting minutes and agendas

CISA ​

CISA hosts several working groups that meet on a weekly basis. The original meeting notes can be found here. Reach out to SBOM@cisa.dhs.gov to get an invite or further information.

SBOM Community Central Meeting
Monday @11am ET
​

VEX sub-group
Monday @10am ET
​

SBOM adoption work stream
Tuesday @12pm ET
​

SBOM tooling work stream
Thursday @3pm ET
​

OpenSSF (SBOM everywhere)
Every other Tuesday @11am ET
​

The SBOM Everywhere Special Interest Group came from OpenSSF’s Open Source Software Security Mobilization Plan. The SBOM Everywhere SIG focuses on improving SBOM tooling and training to drive adoption. It's also running this site. Further information in the about us section.

Anchore OSS Community Meeting
Every other Thursday @11am ET
​

Anchore is hosting a community meeting for their open source projects Syft and Grype.

- + \ No newline at end of file