Section four of the “Executive Order on Improving the Nation’s Cybersecurity” introduced a lot of people in tech to the concept of a “Software Supply Chain” and securing it. If you make software and ever hope to sell it to one or more federal agencies, you have to pay attention to this. Even if you never plan to sell to a government, understanding your Software Supply Chain and learning how to secure it will pay dividends in a stronger security footing and the benefits it provides. This article will look at three ways to supercharge your Software Supply Chain Security.
What is your Software Supply Chain? It’s essentially everything that goes into building a piece of software: from the IDE in which the developer writes code, to the third-party dependencies, to the build systems and scripts, to the hardware and operating system on which it runs. Instabilities and vulnerabilities can be introduced, maliciously or not, from inception to deployment and even beyond.
Some of the bigger cybersecurity incidents of 2023 occurred because bad actors found secrets in plain text. Secrets, in this context, are things like username and password combos, API keys, signing keys, and more. These keys to corporate kingdoms were found laying around where they shouldn’t be.
Sourcegraph got pwned when they published code to a public instance containing a hardcoded access token. The token was used to create other accounts and give people free access to the Sourcegraph API. A hacker group got access to a Microsoft internal debugging environment and found a signing key in a crash dump that let them create email credentials.
Tools like GitGuardian allow you to check your code, both legacy and bleeding edge, for accidentally published secrets or attempts to publish them. It’s important to know which secrets might have been released and remediate them, as well as put in safeguards in the form of automated tools and code reviews to ensure other keys don’t get out.
In manufacturing, a Bill of Materials (BOM) is a comprehensive inventory that includes all raw materials, components, and guidelines necessary for the construction, manufacturing, or repair of a product or service. Both cybersecurity regulations and best practices are embracing the idea of a software BOM that provides transparency and provenance of all the pieces that go into building your software.
But you just can’t build a BOM from your list of declared dependencies.
Package repositories like NPM, PyPI and the incorporation of open-source frameworks and libraries were hailed for making software development more efficient by not having to reinvent the wheels. Instead, developers could find free packages that implemented the functionality they needed and incorporate them into their software easily.
They also exposed developers to a growing web of dependencies. You may find it feels like “turtles all the way down” as your dependencies have dependencies that have dependencies… You might even have sub-dependencies on four different releases of the same package, all of which have different vulnerabilities.
Software Composition Analysis tools automatically scan your project’s codebase and identify all the external components you’re using, including all the turtles as far down as they go. They then perform checks to make sure these components are up-to-date, secure, and compliant with licensing requirements.
This not only helps to identify which dependencies have known exploits so you can update or replace them, but that’s a big help when you need to generate a clean BOM for inspection by potential customers and regulators.
Ethical hacking is older than most recent CS grads. As stated in a recent webinar on ethical hacking, it is “identifying and exploiting vulnerabilities in computer systems or networks in a responsible and lawful manner.” Note the emphasis on “responsible” and “lawful.”
Essentially, ethical hackers use most of the same techniques as “black hat” hackers to find and exploit vulnerabilities in a system. The difference that cannot be stressed enough is that they do it with permission. They stick to the systems they’ve been given permission to hack, then document everything so that their discoveries can be reproduced and analyzed by the team/client to whom they report them.
While this can often come in a later stage in the development process, it’s important. If they can determine your dependencies and do their own SCA that identifies vulnerable dependencies, game over. If they can find an unguarded point of entry, game over. If they test a web app and find debug code outputting confidential output in the console, game over. Some vulnerabilities can be show-stoppers, some might be just needing to remove a line of debug code.
Making ethical hacking part of the release process, joining bug bounty programs, and more can make sure you’re fixing things before you’re having to apologize for them, report them to regulators, and do clean-up.
Whether you’re trying to please regulators or customers, beefing up your Software Supply Chain Security will let you spend more time selling your software and less time apologizing for it. And while these three tips get you a good foundation, you can find a lot more in the SLSA security framework. Working the framework and securing your supply chain is how you get (in the words of the SLSA site) “from ‘safe enough’ to being as resilient as possible, at any link in the chain.”
