SnykSecOn September 14, the White House released Executive Order M-21-30, emphasizing and reminding us that there are NIST guidelines for securing any software being sold to the US Government. According to the Executive Order (EO), self-attestation is a requirement for software vendors or agencies and acts as a “conformance statement” outlined by the NIST Guidance.
As per the EO, the attestation form should have the following details:
- The software producer’s name
- Software name
- Statement from the vendor or agency highlighting that they followed secure development practices
The executive order mandates that every vendor needs to provide a self-attestation form, which affirms their secure development practices that create the foundation for developing secure software.
Why the US Government cares about the software supply chain, and you should too
In December 2020, there was a significant software supply chain attack on SolarWinds. Following the same series of incidents in May 2021, the White House released Executive Order 14028 which addressed improving the nation’s cybersecurity. Although the media focus centered on the software bill of materials (SBOM), the executive order provided more holistic guidance. An SBOM is useful tool to know everything going into your software, but there are important considerations for people, process, and tools and responding to vulnerabilities that are critical as well. Even if your company is not selling software to the US government, these practices are important to reduce risk in your development practices.
What are secure development practices?
Following Executive Order 14028, the National Institute of Standards and Technology (NIST) released the Secure Software Development Framework NIST SP 800-218 (SSDF) VERSION 1.1, which highlighted different aspects of the secure development environment. In March 2022, the White House released an advisory statement around software security and safeguarding the organization, which Snyk supported as well.
The SSDF NIST framework has categorized the security practices into four groups that support or align with the executive order.
Prepare the Organization (PO): Organization’s people, processes, and infrastructure are ready for the new technologies.
Protect the Software (PS): No tampering and unauthorized access.
Produce Well-Secured Software (PW): Well-secured software with minimal security vulnerabilities in its releases.
Respond to Vulnerabilities (RV): Identify residual vulnerabilities in software releases and respond appropriately.
In the wake of this announcement, software vendors are working to adhere to the guidelines of Executive Order 14028 and SSDF. Thankfully, Snyk has the built in capabilities you need to meet the requirements of section 4(e) i.e Enhancing Software Supply Chain Security. There are multiple subsections under 4(e), and Snyk can help you meet compliance standards for each of them.
Section 4e (i)
This section talks about securing software development environments that have separate build environments, audited trust relationships, multi-factor authentication (MFA), conditional access, and encryption of data.
NIST guidance
SSDF framework tasks prepare the organization to have separate, secure environments (PO.3.2, PO.3.3, PO.5.1, PO.5.2) with restrictive access and monitoring.
How Snyk can help
As you set up your separate, secure environments, and the various tools that each team needs in their respective environment, Snyk allows you to manage access in different environments and groups. Within each organization, developers monitor their code, 3rd party dependencies, and associated vulnerabilities. Organizations can set up single sign-on (SSO) to give development and security teams easy access to Snyk through your existing SSO provider.
Access rights are based on role based access control, and can be checked and edited in the Snyk UI.
We can also manage email notifications and alert policies to notify developers of new security issues automatically.
With Snyk, we can check the code bases and issues in the separate environments.
Section 4e (ii)
This section discusses generating and, when requested by a purchaser, providing artifacts that demonstrate conformance to the processes set forth in the previous subsection, (e)(i).
NIST guidance
The PO subsections — PO.3.2, PO.3.3, PO.5.1, and PO.5.2 — are well aligned with section 4e (ii) of the Executive order, which provides guidance on caring for environment tools and configuring them to appropriately provide artifacts to secure development environments.
How Snyk can help
Snyk’s reporting features allows it to capture and monitor the artifacts surrounding vulnerabilities. Additionally, Snyk helps automate the DevOps pipeline by integrating the artifacts with other tools.
Section 4e (iii)
This section states that organizations must employ automated tools, or comparable processes, to maintain trustworthy source code supply chains and ensure the integrity of their code.
NIST Guidance
The section talks about maintaining trusted source code supply chains, defining requirements, and maintaining a list of vulnerabilities.
SSDF Practice and Task Reference Numbers [PO.3.1, PO.3.2, PO.5.1, PO.5.2, PS.1.1, PS.2.1, PS.3.1, PW.4.1, PW.4.4], which provide guidance on maintaining source code supply chains, defining requirements, and maintaining a list of vulnerabilities, apply here.
How Snyk can help
The Dependencies report in Snyk serves as a bill of materials for all projects in the chosen organization’s direct dependencies. It looks something like this:
Snyk can scan these dependencies — and their transitive/indirect dependencies — early in the development pipeline so security issues can be addressed as soon as possible.
In addition, Snyk automates package health checks in the IDEs used by developers. This provides immediate feedback to developers on vulnerable packages, but can also alert developers to packages that may be unsafe for other reasons, such as inactive maintenance.
Section 4e (iv)
This section requests that vendors check for known and potential vulnerabilities, and remediate them with the regular updates in softwares and dependencies.
NIST Guidance
Check software for vulnerabilities and remediate them according to the following sections of the SSDF framework: PO.4.1, PO.4.2, PS.1.1, PW.2.1, PW.4.4, PW.5.1, PW.6.1, PW.6.2, PW.7.1, PW.7.2, PW.8.2, PW.9.1, PW.9.2, RV.1.1, RV.1.2, RV.2.1, RV.2.2, RV.3.3.
How Snyk can help
Snyk provides actionable fix advice for vulnerabilities in your open source libraries, using both automatic and manual pull requests (PRs) and merge requests (MRs).
Section 4e (v)
This section states that organizations should, when requested by a purchaser, provide artifacts of the execution of the tools and processes described in subsection (e)(iii) and (iv) of this section, and make summary information on the completion of these actions publicly available — including a summary description of the risks that were assessed and mitigated.
NIST Guidance
4e(v) Provide artifacts from 4e(iii) and 4e(iv) upon request, and make a summary description of risks assessed and mitigated publicly available, according to PO.3.2, PO.3.3, PO.4.1, PO.4.2, PO.5.1, PO.5.2, PW.1.2, PW.
How Snyk can help
When Snyk finds a vulnerability, it can automatically open a pull request for the developers to address — which can help organizations find and fix vulnerabilities and remediate them more efficiently.
Section 4e (vi)
This section establishes the need to maintain accurate and up-to-date data, provenance (i.e., origin) of software code or components, and controls on internal and third-party software components, tools, and services present in software development processes — in addition to performing audits and enforcing these controls on a recurring basis.
NIST Guidance
4e(vi) Maintain provenance data for internal and 3rd party components, in compliance with PO.1.3, PO.3.2, PO.5.1, PO.5.2, PS.3.1, PS.3.2, PW.
How Snyk can help
After raising a pull request, Snyk gives developers the option to merge or deny the vulnerability report based on severity level and other circumstances.
Section 4e (vii)
This section talks about providing a SBOM for each product directly, or publishing it on a public website, so purchasers can assess your application with full transparency.;
NIST Guidance
Maintain and share provenance data for all components of each software release
for each product, covering section PS.3.2.
How Snyk can help
Snyk makes providing a SBOM for an application simple by finding and highlighting third party dependencies in code and container images, along with security risks and vulnerabilities for affected packages. Snyk has always allowed users to export this data in CSV or via the API, but recently new standards like CycloneDX and SPDX have emerged. Snyk’s SBOM export capability is currently in beta, and is in conformance with subsection.
Section 4e (viii)
This section explains that organizations are required to participate in a vulnerability disclosure program that includes a reporting and disclosure process.
NIST Guidance
Participate in a vulnerability disclosure program, according to RV.1.1, RV.1.2, RV.1.
How Snyk can help
The Snyk Security Researchers are constantly finding new research topics and interesting open source issues to share. Snyk also has a responsible disclosure program for reporting new security vulnerabilities.
Snyk supports environments which are developer friendly by being compatible with most popular languages , IDEs , and CI/CD tools — and our coverage is constantly expanding.
While Snyk is supporting the Executive Order and SSDF framework, we’re also contributing to the security of various open source environments — as described in our 2022 State of Open Source Security Report. This annual report started in 2018, and this year we had the chance to co-author it with the Linux Foundation, one of the largest and most reputable open source organizations in the world.
We found that software composition analysis (SCA) and static application security testing (SAST) tools are the top two tools used by organizations to address security issues. This is important to note, as 73% of organizations are actively looking for best practices to increase their software security and these are two tools types that can help them do so.
Our open source report turned up some interesting finds, from trust issues in open source to how much time development teams lost by fixing security issues themselves.
- Only 18% of organizations have confidence in their applications’ transitive dependency controls. The typical application development project has 80 direct dependencies and 49 vulnerabilities.
- OS projects take 110 days on average to fix vulnerabilities, 20% longer than proprietary projects. Transitive dependencies are used to identify 40% of all vulnerabilities.
- 41% of businesses have low confidence in the security of open source software.
Don’t allow weak links in the software supply chain
Executive Order 14028 and Secure Software Development Framework serve as guides to help all organizations, but especially those in the tech industry, secure their personal supply chains and promote a better and more secure environment for the nation as a whole.
While complying with this and other executive orders is a priority for any organization, the transition person can seem overwhelming at first. Adjusting to new security standards without disrupting development demands a tool set that gives you a holistic view of your application. Snyk’s developer-first security platform can help you mitigate risk across your software supply chain, making the transition as seamless and secure as possible.
Ready to see Snyk in action?
Book a demo with one of our security experts to see how Snyk can save you time and money.
