Skip to content

Commit

Permalink
Merge pull request #57 from ossf/adriandiglio-patch-4
Browse files Browse the repository at this point in the history
Update UPD-3
  • Loading branch information
adriandiglio authored Aug 27, 2024
2 parents a08b79e + d340b11 commit f9e3148
Showing 1 changed file with 3 additions and 3 deletions.
6 changes: 3 additions & 3 deletions specification/framework.md
Original file line number Diff line number Diff line change
Expand Up @@ -320,7 +320,7 @@ Below is a table of the requirements mapped to the 8 different practices. Two of
| | INV-2 | L2 | Have an OSS Incident Response Plan | This is a defined, repeatable process that enables your organization to quickly respond to reported OSS incidents |
| *Update It* | UPD-1 | L1 | Update vulnerable OSS manually | Ability to resolve vulnerabilities |
| | UPD-2 | L2 | Enable automated OSS updates | Improve MTTR to patch faster than adversaries can operate |
| | UPD-3 | L2 | Display OSS vulnerabilities as comments in Pull Requests (PRs). <br /> **Prerequisite**: Two-person PR reviews are enforced. | PR reviewer doesn't want to approve knowing that there are unaddressed vulnerabilities. |
| | UPD-3 | L2 | Display OSS vulnerabilities in developer contribution flow (i.e. Pull Requests). <br /> **Prerequisite**: Two-person PR reviews are enforced. | PR reviewer doesn't want to approve knowing that there are unaddressed vulnerabilities. |
| *Audit It* | AUD-1 | L3 | Verify the provenance of your OSS | Able to track that a given OSS package traces back to a repo |
| | AUD-2 | L2 | Audit that developers are consuming OSS through the approved ingestion method | Detect when developers consume OSS that isn&#39;t detected by your inventory or scan tools |
| | AUD-3 | L2 | Validate integrity of the OSS that you consume into your build | Validate digital signature or hash match for each component |
Expand Down Expand Up @@ -351,7 +351,7 @@ This table maps each Framework requirement to corresponding level and Framework
| **Ingest it** – save a local copy of artifacts and source code | [**ING-1**] Use package managers trusted by your organization <br /> [**ING-2**] Saving a local copy of the OSS artifact can be done by adopting an integrated package caching solution into your CI/CD infrastructure. All developers across your organization should standardize their consumption methods (using governed workflows) so that security policy can be enforced. <br /><br /> **Free Tools:** [VCPKG for C/C++ OSS](https://github.com/Microsoft/vcpkg), [Pulp](https://pulpproject.org/) <br /> **Paid Tools:** [Artifacts](https://docs.microsoft.com/en-us/azure/devops/artifacts/start-using-azure-artifacts?view=azure-devops), [GitHub Packages](https://github.com/features/packages), [Azure Container Registry](https://docs.microsoft.com/en-us/azure/container-registry/container-registry-get-started-portal), [PackageCloud](https://packagecloud.io/) | | [**ING-3**] Having a Deny List capability to block ingestion of vulnerable and malicious OSS components is a required defensive tool in incident response situations. Having an incident response team that can rapidly respond and update the deny list is also critical. <br /><br /> **Paid Tool:** [Nexus Firewall](https://www.sonatype.com/products/firewall) <br /><br /> [**ING-4**] Saving a local copy of the OSS source code <br /><br /> **Free Tool:** [Duplicating a repo](https://docs.github.com/en/repositories/creating-and-managing-repositories/duplicating-a-repository) | |
| **Scan It -** for vulnerabilities and malware | [**SCA-1**] It is required to scan for known vulnerabilities of your dependencies. Choosing a tool that gets vulnerabilities from more places than just CVEs is important to ensure that you are being informed from across multiple vulnerability sources. <br /><br /> **Free Tool:** [GitHub Dependency Graph](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph) <br /> **Paid Tool:** [Snyk Open Source](https://snyk.io/product/open-source-security-management/), [Mend SCA](https://www.mend.io/sca/) <br /><br /> [**SCA-2**] In addition to scanning for vulnerabilities, OSS should be scanned for software licenses. <br /><br /> **Free Tool:** [ScanCode](https://github.com/nexB/scancode-toolkit) | [**SCA-3**] Scanning OSS to determine if it is end of life is crucial to ensure that you are not taking dependencies on OSS that is no longer updated. <br /><br /> **Free Tool**: [OpenSSF Scorecard](https://github.com/ossf/scorecard) | [**SCA-4**] Given the rise in malicious OSS packages over the years, it is critical that OSS be scanned for malware prior to consumption. <br /><br /> **Free Tool:** [Mend Supply Chain Defender](https://www.mend.io/mend-supply-chain-defender/), [OpenSSF Package Analysis](https://github.com/ossf/package-analysis) <br /> **Paid Tool:** [Nexus Firewall](https://www.sonatype.com/products/firewall), [Checkmarx SCA](https://checkmarx.com/resource/documents/en/34965-19105-preventing-supply-chain-attacks.html) <br /><br /> [**SCA-5**] Without doing proactive security analysis to look for zero-day vulnerabilities, there would be entire threat categories that would go unmitigated, such as back-doors. <br /><br /> **Free Tools:** [OSSGadget](https://github.com/microsoft/OSSGadget), [DevSkim](https://github.com/microsoft/DevSkim), [Attack Surface Analyzer](https://github.com/microsoft/AttackSurfaceAnalyzer), [Application Inspector](https://github.com/microsoft/ApplicationInspector), [CodeQL](https://codeql.github.com/), [OneFuzz](https://github.com/microsoft/onefuzz), [RESTler](https://github.com/microsoft/restler-fuzzer) <br /> **Paid Tool:** [Semgrep](https://semgrep.dev/) | |
| **Inventory It -** OSS usage and deployment | [**INV-1**] Establishing an inventory of all developer OSS dependencies is critical when responding to an incident as an ingested malicious component would need to be deleted from the developer&#39;s desktop, the package caching solution, and the software/service that in production that consumed the package. Knowing which projects are using which OSS components and their versions across your enterprise is vital toward supporting rapid Incident Response. <br /><br /> **Free Tool**: [Component Detection](https://github.com/microsoft/component-detection), [SBOM Generator for 1st party code](https://github.com/microsoft/sbom-tool), [Syft](https://github.com/anchore/syft), [Tern](https://github.com/tern-tools/tern), [SCA tooling](https://github.com/bureado/awesome-software-supply-chain-security#sca-and-sbom) <br /> **Paid Tool**: [Dependency Graph w/ Insights](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/viewing-insights-for-your-organization#viewing-organization-dependency-insights) via [GHAS](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) | [**INV-2**] Have an incident response plan that leverages your inventory and your deny list. <br /><br /> **Free Tool:** [Incident Response Reference Guide](https://www.microsoft.com/en-us/download/details.aspx?id=103148) | | |
| **Update It** | [**UPD-1**] Update vulnerable OSS manually. | [**UPD-2**] Automating patching OSS dependencies to address known vulnerabilities in a timely manner. <br /><br />**Free Tool**: [Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts), [Renovate](https://github.com/renovatebot/renovate) <br /><br /> [**UPD-3**] Display OSS vulnerabilities as comments in Pull Requests. <br /><br /> **Paid Tool**: [Dependency Review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review) via [GHAS](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) | | |
| **Update It** | [**UPD-1**] Update vulnerable OSS manually. | [**UPD-2**] Automating patching OSS dependencies to address known vulnerabilities in a timely manner. <br /><br />**Free Tool**: [Dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-alerts/about-dependabot-alerts), [Renovate](https://github.com/renovatebot/renovate) <br /><br /> [**UPD-3**] Display OSS vulnerabilities in developer contribution flow (i.e. Pull Requests). <br /><br /> **Paid Tool**: [Dependency Review](https://docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review) via [GHAS](https://docs.github.com/en/enterprise-server@3.4/get-started/learning-about-github/about-github-advanced-security) | | |
| **Audit It -** provenance and consumption workflows | | [**AUD-2**] Audit that developers are consuming OSS through the approved ingestion method. You can search for binaries that are checked into the repo. <br /><br /> **Free Guide**: [Searching Code](https://docs.github.com/en/search-github/searching-on-github/searching-code) <br /><br /> [**AUD-3**] Validate integrity of the OSS that you consume into your build. <br /><br /> **Free Tool**: [NuGet CLI verify command](https://docs.microsoft.com/en-us/nuget/reference/cli-reference/cli-ref-verify), | [**AUD-1**] Verify the provenance of all OSS components to ensure they come through the official supply chain. <br /><br /> **Paid Tool**: [Nexus Firewall](https://www.sonatype.com/products/firewall) | [**AUD-4**] Validate the SBOMs of OSS that you consume into your build. <br /><br /> **Free Tool**: [Community Attestation Service](https://cas.codenotary.com/) |
| **Enforce It -** OSS consumption meets security policy | | [**ENF-1**] Securing the configuration of how build pipelines consume OSS components. <br /><br /> **Free Tools:** [NuGet Package Source Mapping](https://docs.microsoft.com/en-us/nuget/consume-packages/package-source-mapping), [Version pinning and Lock Files](https://azure.microsoft.com/mediahandler/files/resourcefiles/3-ways-to-mitigate-risk-using-private-package-feeds/3%20Ways%20to%20Mitigate%20Risk%20When%20Using%20Private%20Package%20Feeds%20-%20v1.0.pdf) | [**ENF-2**] Enforcing teams to only consume packages from a curated feed is the goal of this Framework. <br /><br /> **Paid Tool**: [Nexus Firewall](https://www.sonatype.com/products/firewall) | |
| **Rebuild It -** from source | | | | [**REB-1**] Rebuilding from source in a trusted build environment removes the risk of consuming a package that may have been victim to a CCleaner/SolarWinds style build-time attack. <br /><br /> **Free Tools:** [Oryx](https://github.com/microsoft/oryx), [DotNet.ReproducibleBuilds](https://www.nuget.org/packages/DotNet.ReproducibleBuilds/), [Reproducible-Builds.org](https://reproducible-builds.org/), [OSS Reproducible](https://github.com/microsoft/OSSGadget/tree/main/src/oss-reproducible), [rebuilderd](https://github.com/kpcyrd/rebuilderd) <br /><br /> [**REB-2**] Digitally sign the OSS you rebuild. <br /><br /> **Tool:** [Notary](http://notaryproject.dev/), [SigStore](https://www.sigstore.dev/) <br /><br /> [**REB-3**] If you are rebuilding the OSS yourself, you can automate Software Bill of Material (SBOM) generation at build time. This helps capture the supply chain information for each package to enable you to better maintain auditability and blast radius assessments. <br /><br /> **Free Tool:** [SBOM Generator](https://github.com/microsoft/sbom-tool) on rebuilt 3rd party code <br /><br /> [**REB-4**] Digitally sign the SBOMs you produce. <br /><br /> **Free Tool:** [Notary](notaryproject.dev) |
Expand Down Expand Up @@ -383,7 +383,7 @@ There are many other security frameworks, guides, and controls. This section map
| INV-2 | Have an OSS Incident Response Plan | **SP800218** : RV.2.2 <br /> **SP800161** : SA-5, SA-8, SA-10, SA-11, SA-15(7) |
| UPD-1 | Update vulnerable OSS manually | |
| UPD-2 | Enable automated OSS updates | |
| UPD-3 | Display OSS vulnerabilities as comments in Pull Requests (PRs) | |
| UPD-3 | Display OSS vulnerabilities in developer contribution flow (i.e. Pull Requests) | |
| AUD-1 | Verify the provenance of your OSS | **CIS SSC SG** : 3.2.4 <br /> **OWASP SCVS:** 1.10, 6.1 <br /> **SLSA v1.0:** Producing artifacts – Distribute provenance |
| AUD-2 | Audit that developers are consuming OSS through the approved ingestion method | **CIS SSC SG** : 4.3.3 |
| AUD-3 | Validate integrity of the OSS that you consume into your build | **CIS SSC SG** : 2.4.3 <br /> **OWASP SCVS:** 4.12 <br /> **CNCF SSC:** Verify third party artefacts and open source libraries |
Expand Down

0 comments on commit f9e3148

Please sign in to comment.