U.S., OpenSSF school dev teams on supply chain security

The U.S. government is schooling developers in a new document, Securing the Software Supply Chain. The NSA, CISA and the Office of the Director of National Intelligence (ODNI) have the lead.

But, oh my, what a lot of words. So many words. Page after page after page of words. Given the number of different agencies involved, it’s no surprise it sounds like it was written by a committee — and one with verbal diarrhea.

Even so, dev teams should try to familiarize themselves with it (especially if you want to sell to governments). In this week’s Secure Software Blogwatch, we achieve full buzzword compliance.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Stop motion cooking.
 

Feds’ big yawndoc

What’s the craic? Phil Muncaster reports — “CISA, NSA and npm Release Software Supply Chain Guidance”:

“Weak link in the supply chain”
The US government has issued new guidance for developers designed to improve the security of the software supply chain, and in so doing make the nation’s critical infrastructure more resilient. … The document consolidates useful resources in a single location to help optimize security in software development.
…
An increasingly targeted weak link in the supply chain is open source repositories. One vendor observed a 650% year-on-year increase in threat actors deliberately injecting new vulnerabilities into these third-party libraries, so they could be exploited downstream.

 
Context plz? David Jones fills in the blanks — “Feds push for developers to take lead”:

“Part of an ongoing debate”
The Biden administration is heavily focused on gaining control over the nation’s critical infrastructure following the SolarWinds supply chain compromise in 2020. A series of historic ransomware attacks, including the May 2021 incident that forced a temporary, but massive fuel disruption at Colonial Pipeline, have heightened the administration’s concerns.
…
The timing of the release is related to the release of Executive Order 14028, which establishes new requirements to secure the software supply chain. … Biden signed the executive order in May 2021 in the aftermath of the SolarWinds and Microsoft Exchange server attacks.
…
The guidelines are part of an ongoing debate in the software and information security industries on when to deal with security flaws, but recent recommendations point to addressing concerns in the development stage. … The guidelines are the first of a three-part series planned by the agencies. Two additional guidelines will be focused on software suppliers and software customers.

 
Your tax dollars at work. Some anonymous feds compile these “Recommended Practices for Developers”:

“Focuses on software developers”
Recent cyberattacks … highlight weaknesses within software supply chains, an issue which spans both commercial and open source software and impacts both private and Government enterprises. Accordingly, there is an increased need for software supply chain security awareness and cognizance regarding the potential for software supply chains to be weaponized by nation state adversaries.
…
The Enduring Security Framework (ESF) … is a cross-sector working group that operates … to address threats and risks to the security and stability of U.S. national security systems. It … is charged with bringing together representatives from private and public sectors to work on intelligence-driven, shared cybersecurity challenges. [The] ESF Software Supply Chain Working Panel has established this guidance to serve as a compendium of suggested practices for developers, suppliers, and customer stakeholders to help ensure a more secure software supply chain.
…
This document … focuses on software developers [and] will provide guidance in line with industry best practices and principles which software developers are strongly encouraged to reference. [It] recommends principles Developers may use to help secure the software development lifecycle (SDLC). … Each section contains examples of threat scenarios and recommended mitigations. Threat scenarios explain how processes that compose a given phase of the … SDLC relate to common vulnerabilities.

 
And so it goes on — and on … and on. u/zenodub sounds slightly sarcastic:

Cool, I'm just going to give this 64 page document to a software developer. I'm sure they'll love that.
…
This seems more geared towards security managers with software development teams.

 
Our own Paul Roberts notes the curious timing — “A roadmap for the post-SolarWinds world”:

“Just another document languishing on a government website”
The U.S. Federal Government has dropped what may be its most significant statement on software supply chain security — on the eve of the last holiday weekend of summer, a time associated more with family barbecues or beach parties than software build processes. [It’s] a must-read for software development organizations concerned about threats to their software development process, including open source risk and sophisticated, SolarWinds-style tampering attacks.
…
The guide succeeds in what might be its most important goal: highlighting the supply chain cyber risk, while also providing something like a roadmap for development organizations to improve defenses. … Another big accomplishment of the supply chain guide is in its function as … a kind of Rosetta Stone for supply chain security. [It] makes a strong recommendation … that development organizations employ binary scanning and software composition analysis (SCA) tools that are capable of detecting unknown files and open source components … hiding within compiled binary packages. … The guidelines rightly identify IDE plugins and scripts as a huge attack surface that goes unchecked by most development organizations. That needs to change.
…
But, like any other guidelines, they are only useful to those development organizations that read them and expend the time, money and human resources needed to implement their recommendations. For everyone else, they're just another document languishing on a government website.

 
Can the private sector do any better? Michael Hill makes a deal with Dog — “OpenSSF releases npm best practices”:

“Shares security guidance”
The Open Source Security Foundation (OpenSSF) has released the npm Best Practices Guide to help JavaScript and TypeScript developers reduce the security risks associated with using open-source dependencies. [It] focuses on dependency management and supply chain security for npm and covers various areas such as how to set up a secure CI configuration, how to avoid dependency confusion, and how to limit the consequences of a hijacked dependency.
…
For example, the first step to using a dependency is to study its origin, trustworthiness, and security posture. It advises developers to look out for typosquatting attacks … by identifying the GitHub repository of the package and assessing its trustworthiness. … Developers should identify the corresponding package name and use OpenSSF Security Scorecards to learn about the current security posture of the dependency. … Developers should also use deps.dev to learn about the security posture of transitive dependencies and npm-audit to learn about existing vulnerabilities in the dependencies of the project.
…
Reproducible installation can ensure that exact copies of dependencies are used each time a package is installed. … Developers should also use a lockfile, which implements hash pinning. … The guide also shares security guidance on package release/publishing and private packages from internal registries.

 
Hopefully a bit more focused? Myles Borins, Jordan Harband, Jeff Mendoza, Erez Rokah, Laurent Simon, Liran Tal and Randall T. Vasquez sound excited — “npm Best Practices”:

“Proactively harden their npm packages”
We are excited to announce the v1 release of the “npm Best Practices,” a new guide focused on dependency management and supply chain security. … It is a critical step to help JavaScript and TypeScript developers reduce risks as they choose open-source dependencies to use in their projects.
…
The ability to use another developer’s project as a dependency has contributed to faster development time, innovation, and a vibrant open-source community. … Using dependencies also incurs risks. … Still, the benefits of using dependencies most often outweigh the downsides. [The] guide is intended to help developers and organizations facing such problems so that they can consume dependencies more confidently.
…
Developers who follow this guide will proactively harden their npm packages against the most common supply chain attacks. … There are many other language ecosystems, and we are looking for help to create more guideline documents to support developers using open source securely.

 
How did we get here? jimrandomh shoos you off his lawn:

“The friction was serving an important function”
It used to be that adding library dependencies to a project had a lot of friction. … If you were writing a library yourself, then imposing indirect dependencies on users was something you'd try fairly hard to avoid.

Then npm came along, with some ideology about code reuse, and the friction went away. But the friction was serving an important function: If adding a library is annoying, you'll add a small number of large libraries rather than a large number of small ones, and you avoid getting an ecosystem where major libraries have hundreds of tiny dependencies [and] trusting too many different developers and developers' computers.

 
Expanding on the theme, here’s cerberusTI:

“Unchecked access to your production systems”
I solve this … by not allowing dependency managers within source code or for programming environments, and not granting enough access to make it easy to get around that. If you want outside software, that requires prior approval of each dependency. Approval requires that you provide a good reason it needs to be included, and is not the default. Anything crossing onto a staging server [is] subject to code review.
…
I have fairly restrictive policies on communications with or resources loaded from outside servers as well, and products which come under my control after development go through some review and remediation for this and other issues. Those interactions are well known and categorized, and difficult to hide. That kind of policy does select for certain types of programmers, but it limits problems … and has some benefits in lessening unintended interactions as well.
…
It is madness to rely upon code which can be updated through a process you do not understand and trust. … You have in effect arranged to give an individual you have no control over unchecked access to your production systems. … Understanding what you depend upon can be enough effort to set a fairly high bar for what is worth including in the end.

 
Meanwhile, Rygian takes issue with the terminology:

There was never a supply "chain" to begin with. If you're looking for a more precise metaphor, think of it as a large pot of slightly overcooked spaghetti and meatballs — where anyone can throw stuff into the pot.

 
And Finally:

How vending machines really work

Previously in And finally

Keep learning

• Learn more about software supply chain security trends
• Get up to speed on the SBOM's evolution
• Download report: NVD Analysis 2022 — A Call to Action on Supply Chain Security
• See survey report: Tampering top of mind for dev — but detection lags

You have been reading Secure Software Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites … so you don’t have to. Hate mail may be directed to @RiCHi or ssbw@richi.uk. Ask your doctor before reading. Your mileage may vary. E&OE. 30.

Image sauce: Sear Greyson (via Unsplash; leveled and cropped)