by Dr. Robert Buccigrossi, TCG CTO

On May 12, 2021, the Biden Administration released the Executive Order on Improving the Nation’s Cybersecurity. This directive seeks “bold changes and significant investments” to “protect and secure” the Federal Government’s computer systems by:

• Section 2 — Promoting the sharing of threat information,
• Section 3 — Modernizing government cybersecurity (such as zero trust architecture),
• Section 4 — Securing the software supply chain,
• Section 5 — Establishing a Cyber Safety Review Board,
• Section 6 — Creating a playbook for responding to vulnerabilities and incidents,
• Section 7 — Improving detection of vulnerabilities and incidents, and
• Section 8 — Increasing investigative and remediation capabilities.

Facing the ever-increasing number and sophistication of attacks against our government’s IT infrastructure, these changes are welcome and needed. There is, however, a reckoning in our industry that will be caused by Section 4: “Enhancing Software Supply Chain Security”.

What Supply Chain Problem? — Back in 2016, a developer removed 17 lines of code from a public repository and caused many web sites to go down. In 2018, a popular library with 2 million weekly downloads was hacked and updated to include bitcoin mining software. Just this past February, a researcher described how typos in library names allowed him to attack the software supply line of dozens of companies including Apple and Microsoft. What are we doing as an industry to create such an attack surface?

Dependency Management — A Software Library House of Cards - Over decades, public repositories of open source software have formed, creating a wonderful world-wide collection of capabilities (such as machine learning) and frameworks (including gaming, rapid application development, and VR). Thanks to transparency and an active community of developers and researchers, open source software offers many security advantages. However, in many popular programming languages (including JavaScript, .NET, Python, Java, and PHP) it has become standard practice to pull required code (“dependencies”) from on-line repositories as the software is being packaged (or compiled) for deployment. Dependency managers such as “Maven”, “Gradle”, “npm”, “pip”, and “NuGet” make it trivial to pull the latest versions of the libraries that our software needs from public repositories, including the dependencies of our direct dependencies, and so on. The result is that it is common to download hundreds of libraries as a piece of software is packaged for deployment — even if that deployment is to a production environment.

Stuck Between a Rock and a Hard Place — As-needed dependency management has a wonderful advantage: We can always get the latest version of a library with bug fixes and security patches. However, downloading libraries at build time increases the chance of malicious code being introduced by library name typos, hacked library accounts, or the acquisition of a library by a malicious actor. As software developers, we need to find the sweet spot between an older software with vulnerabilities (a rock) and brand new software that has not yet been vetted for vulnerabilities (a hard place). In addition, the Cybersecurity Executive Order requires the Federal Government to take action “to rapidly improve the security and integrity of the software supply chain.” In the face of real-time dependency downloads, how is this possible?

Back to Configuration Management Basics — The primary goal of configuration management is to make sure that changes to our software are controlled and understood. To do this we need to:

• When possible, use secure and vetted repositories — For repositories and operating systems such as Red Hat Enterprise Linux (RHEL), a commercial entity (e.g. IBM Red Hat) takes responsibility for the auditing and configuration management of the libraries within the repository. When using an environment like RHEL, we choose security and convenience over having the cutting-edge versions of software libraries.
• Otherwise, place open source libraries under configuration management - When secure and vetted libraries are not available, it becomes our responsibility to audit and review the libraries we include in our software. This includes: 
  • Commit library source code into our project’s repository — If we place our dependency source code in our repository, we can then directly track and control changes.
  • Use audit tools to search for known library vulnerabilities - Tools like “npm audit” and “dotnet –vulnerable” allow us to search vulnerability databases for known exploits in the libraries and versions we are using.
  • Conduct configuration management audits - When we upgrade libraries, the team should use linting tools (static code vulnerability analysis) and visual scanning of code updates to understand and vet changes. When we commit library source code into our project’s repository we are able to conduct a “diff” and see exactly what has changed in our dependencies.
• Deliberately control the versions of dependencies - We should never jump to the latest version of a library because it is there, but instead control when and understand why an upgrade is needed (such as a known security vulnerability or a required feature). Such upgrades are baselined with our source code and need to go through full change management, promotion, and testing before being released to production.

The Day of Reckoning — Within 180 days of the Cybersecurity Executive Order — by November 8, 2021 — the Director of NIST is to publish preliminary guidelines for enhancing software supply chain security. I suspect that our industry’s widespread use of as-needed dependency downloads will be deemed anathema. Fortunately, by following well-known configuration management best practices, we will be prepared.

[Image Credits: House of Cards, Stuck Between a Rock and a Hard Place]