Skip to main content
U.S. flag

An official website of the United States government

Official websites use .gov
A .gov website belongs to an official government organization in the United States.

Secure .gov websites use HTTPS
A lock ( ) or https:// means you’ve safely connected to the .gov website. Share sensitive information only on official, secure websites.

NICE eNewsletter Fall 2022 Industry Spotlight

For More Secure Code, Cybersecurity Needs to Shift Left

By David A. Wheeler, Director of Open Source Supply Chain Security, The Linux Foundation

Cybersecurity is vitally important. However, the 2020 subversion of SolarWinds’ Orion showed that addressing cybersecurity primarily in operations is too little and too late. The attackers were able to insert malicious code during a supplier's build process (the process creates the executable software that would be distributed). Activities like adding sandboxes and twiddling configuration settings do not transform insecure software into secure software.

To have secure systems, we need more developers who create and deploy secure software. That is where the defensive work of cybersecurity begins. Fixing root causes by improving earlier processes is often called shifting left.

To do this, software developers must first know how to develop secure software. The newly released publication from NSA, CISA and ODNI, Securing the Software Supply Chain: Recommended Practices Guide for Developers specifically noted the need for Secure Software Development/Programming Training. Unfortunately, software developers are usually not taught this:

  • In 2019, none of the top 40 US schools or top 5 non-US Computer Science schools required that students learn how to implement secure software (per Forrester).
  • In 2022, of U.S. News' top 24 Computer Science schools, only the University of California - San Diego requires secure coding for its Computer Science undergraduates.
  • The 2022 The State of Developer-Driven Security Survey by Secure Code Warrior found 89% of developers self-report receiving “sufficient training” in secure coding. However, most were not familiar with common software vulnerabilities, didn’t know how to avoid them, and were still knowingly shipping vulnerabilities. In short: they were self-deceived.

It’s particularly damaging when this knowledge gap impacts open source software (OSS). In OSS, users have the freedom to run (for any reason), copy, distribute, study, change and improve the software (see the Open Source Definition). The average amount of OSS inside applications is between 70% through 90%!

Organizations are working to improve developer education and training. The Linux Foundation’s Open Source Security Foundation (OpenSSF) has developed a free online course on developing secure software. OpenSSF also helped fund the OWASP Security Knowledge Framework (SKF). The OpenSSF will develop & distribute more education material per OpenSSF’s OSS Security Mobilization Plan.

Additionally, one can look to the NICE Workforce Framework for Cybersecurity for knowledge and skills statements relevant to two work roles related to secure software: the Software Developer and Secure Software Assessor Role.

Software developers need to learn and apply, e.g.:

  1. Requirements. What are the security requirements for a given system?
  2. Architectural Design. What are the key secure design principles (e.g., least privilege)? Can you analyze designs for security using threat modeling?
  3. Evaluation. Do you evaluate a component’s security before adding it?
  4. Implementation. Do you use acceptlists (not denylists) to constrain untrusted inputs? Do you know the common kinds of vulnerabilities (e.g., the “CWE Top 25” and “OWASP top 10”) and how to prevent them?
  5. Verification. Are you applying different kinds of tools to detect vulnerabilities before release as part of your continuous integration (CI) pipeline? Do you have a good automated test suite with negative tests? When a vulnerability is found in a dependency, can you be quickly alerted, update, and distribute the update?
  6. Distribution. Are you protecting your build and distribution systems?

The OpenSSF’s recently-released Concise Guide for Developing More Secure Software provides specific recommendations for developers.

Here are a few ways those operating production systems can encourage addressing the root causes of many security incidents: 

  1. Evaluate software security before accepting it. If it’s OSS, consider using the OpenSSF’s Concise Guide for Evaluating Open Source Software.
  2. Protect your supply chain. Double-check names and check digital signatures (e.g., using Sigstore).
  3. Plan to ask for Software Bill of Materials (SBOMs) and use them. Industry is working on providing SBOMs. Analyze SBOMs, where available, to determine your risk from components with known vulnerabilities.
  4. Switch from DevOps to DevSecOps. That is, integrate security into DevOps.
  5. Work with your software suppliers, especially OSS, to improve security in the components you most depend on.
  6. Improve security information sharing with software suppliers.
  7. Encourage educational institutions to educate and teach how to develop secure software.
  8. Get involved with other like-minded organizations. This includes the Linux Foundation’s Open Source Security Foundation (OpenSSF) and the Open Web Application Security Project (OWASP).

Anyone who is developing software needs to recognize their role in creating secure software. As more organizations pay attention to this, we can hope to see more secure software being developed and deployed.

NICE eNewsletter Fall 2022

Created October 26, 2022