Developer Endpoint Governance
A software bill of materials (SBOMs) is not a silver bullet that instantly manages the security of a software supply chain. The SBOM is just another layer of cyber defense in a complicated software product environment. NIST SP 800-218, Secure Software Development Framework (SSDF), advocates for SBOM adoption, specifically consumption of SBOMs, and much more. Holistically, the SSDF requires governance of the software development ecosystem. But what does that exactly mean?
For decades, software developers have enjoyed easy access to administrator rights on their development end points. Developers accustomed to operating in highly regulated environments have learned to cope with the lack of administrator rights, albeit at the speed of productivity. Most commercial software developers struggle to imagine operating in an environment where they cannot simply download frameworks, libraries, and tools whenever they feel like it. It isn’t uncommon for software developers to reject a professional opportunity simply because they don’t like the tooling used to build a software product.
Who among us hasn’t been in the room when a developer performs the most egregious act of downloading a tool, from some random location served up by Google, and then proceeding to install that tool using their administrator rights. Instead of reading the license agreement, the developer quickly clicks on the Agree button, and then immediately starts experimenting with the tool to determine if it might scratch an itch. What makes this act so egregious? Neither anti-virus nor endpoint detection and response (EDR) protections are powerful enough to instantly stop a complex software supply chain attack. Neither of those tools read and understand the license agreement of that tool, which may ship the source code off to a remote server for evaluation, and in doing so provide the host of the service permission to store and use the source code as they see fit under a perpetual royalty-free agreement. Goodbye intellectual property rights!
Secure development lifecycles start with establishing governance at the developer endpoint. Yes, this means developers may no longer have administrator rights, it means that the developer may have to ask before they try, but it doesn’t necessarily mean that software development crawls along pushing paper and waiting for permission to experiment. So, what is the goal of governance, and how do we find balance in an age where agility is so highly valued?
Governance is recognizing that software teams must do the right things and verify that the right things were done. At its essence, the concept of governance shouldn’t evoke a visceral response in a developer because we already see shades of this occurring with code reviews before a merge operation occurs. The developer believes they did the right things (they wrote clean and self-documenting code), and they rely on their peers to verify that the right things were done (no obvious algorithmic problems, team code standards were followed, no race conditions, etc.).
Taking a step back, the SSDF and its 42 tasks recognize that software flaws and vulnerabilities will continue to occur regardless of how diligent the team is in its governance practices. The language of every business, even a Silicon Valley software company, is risk. The SSDF, when considered as a singular thing, is about mitigating software development risk to achieve a low residual risk. There is a lot to unpack in this paragraph for an in-the-trenches software developer.
Business risk in a capitalist economy is merely a reference to the possibility that the business may fail because of uncertainty. Economies are difficult to measure and predict. New products may have been well received by early adopters but fail to gain market traction. Something like ChatGPT may arise on a Monday morning and jeopardize the business. There are real risks in software development, too. Risk of losing control of precious source code, risk of data loss in production due to a malformed SQL statement, risk of a Cloud provider going offline for multiple days due to a botched switch firmware upgrade.
Mitigating a risk occurs when steps are taken to reduce the impact of that risk. Using the malformed SQL statement example, multiple mitigations could be applied. First, every SQL statement must be tested against the QA environment before it is permitted to execute in production. Second, a robust database backup strategy could be overlayed that takes database snapshots that supports an acceptable mean time to restore (MTTR). For a given risk, these mitigations result in residual risk, or the risk that remains and cannot be reduced further by controls. For example, every major cloud service provider seemingly suffers a major outage every year. It may not be cost effective for a software service with tight profit margins to operate a multi-cloud strategy, therefore the residual risk of a database failure coinciding with a major outage that fails to meet the MTTR objective becomes an accepted business risk.
Now, take this idea of risk, mitigations, and residual risk and apply them to every aspect of the software development lifecycle. Quickly one can discern that SBOMs provide risk mitigation across parts of the software supply chain, but they offer minimal protection against the egregious example of the developer downloading a new tool, installing it, and using it to analyze the source code.
And that brings us back to governance. The SSDF and its 42 tasks are really intended to drive the whole organization to consider software development activities for what they are: a risk filled manufacturing process. At the heart of this process sits the developer endpoint, the mixing bowl of ingredients pulled from the kitchen pantry, the developer’s mind, and some contributor named Jonathan that no one knows who has a nifty sounding tool packaged up and easily installed via Homebrew.
A secure development lifecycle must include governing the developer endpoint. Establishing a process to safely evaluate, document, and manage everything that a developer requires to build software is a must. The SSDF is a descriptive framework. This means the precise structure of the governance process is up to the team or organization to define. If the process stifles productivity the SSDF is not at fault! Teams should embrace continuous improvement principles and collaboratively work to establish effective governance of the developer endpoint with a nominal impact on productivity.
One way to introduce governance is to adopt tooling such as GitPod or Coder that shifts the development environment into a cloud ecosystem. Tools like these are effectively software development environments as code, establishing a pre-configured environment with everything required to be productive. If a new tool is needed, the container image needs to be updated, and regular code review processes can be applied.
Preparing for SSDF compliance shouldn’t be painful, but it does require education and involvement of the whole organization, from the board room to the team room. If you're just beginning your SSDF journey, installing a governance process around the developer endpoint is a great first step.
