Spectra Assure Free Trial
Get your 14-day free trial of Spectra Assure for Software Supply Chain Security
Get Free TrialMore about Spectra Assure Free Trial
The Biden Administration’s Executive Order 14028 (EO) for Improving the Nation’s Cybersecurity, released in May of 2021, laid out new guidelines for securing software used by federal agencies. Among other things, it set new guidelines for software supply chain security, and empowered the Office of Management and Budget (OMB) to require agencies to comply with those guidelines.
More recently, on September 14, 2022, that guidance took form with the publication of the OMB’s memorandum M-22-18 requiring federal agencies to comply with NIST guidance on software supply chain security, including compliance with NIST Special Publication 800-218 on developing a secure software development framework and subsequent NIST guidance on software supply chain security.
Here's a look at the key elements of the EO and related software supply chain security guidance from the federal government.
Special Report: https://www.reversinglabs.com/the-state-of-software-supply-chain-security
The memo also set out a timeline for federal agencies to communicate new software security requirements to their vendors, and for software publishers that sell to federal agencies to self-attest to the security of their wares. That deadline is 270 days from the release of the OMB memorandum for vendors who sell “critical” software and services to federal agencies. Vendors selling non-critical software have one year to comply.
The mandate opened the door to federal agencies requiring the creation of Software Bills of Materials (SBOMs) that they can use to identify, track and monitor individual components within larger applications and services. The new White House memo does not require software publishers to use — or federal agencies to require — the creation of an SBOM to validate their attestation. However, the language in the memo makes clear that an SBOM “may be required” by an agency as part of solicitation requirements, especially for software deemed as “critical.”
So-called "known unknowns" should also be included for completeness. The Biden memo echoes that guidance as well, instructing agencies to direct publishers to identify practices to which they cannot attest, along with practices they have in place to mitigate those risks.
SBOMs aside, other forms of attestation may also be required, including output from source code analysis and vulnerability scanning tools, in addition to or in lieu of an SBOM, as needed. Publishers may also need to show that they participate in a vulnerability disclosure program.
The NSA, CISA and ODNI released The Enduring Security Framework (ESF), a new set of practice guidelines, in September, 2022. The ESF provides a roadmap for software vendors that do business with the federal government on how to implement a secure software development framework (SSDF) as envisioned by the EO.
The ESF practice guidelines heavily reference other secure development frameworks, including NIST’s Secure Software Development Framework (SSDF), the OWASP Software Component Verification Standard (SCVS) and Supply Chain Levels for Software Artifacts (SLSA). They make clear that federal contractors and agencies need to develop proficiency in areas that they have not prioritized until now.
For example, the guidelines recommend that development organizations use binary scanning and software composition analysis (SCA) tools that can detect unknown files and open source components, and their associated security weaknesses, hiding within compiled binary packages.
Binary scanning can reveal possible threats such as backdoors, out of scope or suspicious functionality that a third-party module may bring with it. Organizations can then use that information when deciding whether to release software to production or if they want to use the module at all.
Likewise, the ESF includes practice guidelines devoted to developing secure code, including recommendations for development organizations to address developer-centric threats. Those include commonplace “ease of development” features like temporary back doors that find their way into production code as well as the risks posed by malicious insiders, rogue developers and compromised development systems.
For example, the guidelines call out the risk posed by integrated development environment (IDE) plugins and scripts — a huge attack surface that goes unchecked in most development organizations.
To address these risks, the ESF recommends that development organizations perform automated static and dynamic testing of newly checked in code to look for vulnerabilities. It also urges them to map newly created code back to clearly identified features, and to implement authentication for code check-ins to guard against compromised development systems.
Critical code — such as that requiring elevated privileges, accessing sensitive resources or using or implementing cryptographic functions — should be subject to mandatory reviews and given a high priority, the guidelines state.
Section 2.3.5 pf the Enduring Security Framework provides recommendations development organizations can follow to secure executable code against exploits. These include:
Image source: Flickr
Researchers have built a worm that reasons about each host it infects, and the open-weight models powering it sit outside safety controls AI providers have built.
While prompt injection and data disclosure remain concerns, excessive agency climbed the list — not surprising with recent security incidents.
The post-mortems of two compromises by rogue AI agents show that security teams need to focus on guardrails, not the AI model.