Endpoint security is a key part of many IT security efforts, but it’s not always thought about in the specific context of software supply chain security.
May 7, 2025
This post is an excerpt from Securing the Software Supply Chain by Michael Lieberman and Brandon Lum. Download the full e-book for free from Kusari.
As I wrote in an earlier post, secure software development starts with developers. This doesn’t just include the people, but also the devices they use to develop — the endpoints. Endpoint security is a key part of many IT security efforts, but it’s not always thought about in the specific context of software supply chain security.
In this post, we’ll consider a standard industry setup where developers are each given their own laptop/workstation to develop on. This includes the developer workstation – the interfacing machine that a developer uses to write software, and also, by extension, the software being run on the developer’s workstation. This includes a set of approved operating systems and tools, including web browsers, remote desktop or SSH clients, and organization-specific applications.
Ideally, the workstation should be as minimal as possible, restricting the number of applications and environments that can be run. This could be done through a Mobile Device Management (MDM) solution to ensure that all devices use only approved software and network/storage policies, and enforce running of endpoint security applications. Providing the identity of devices is also important and, where possible, solutions should use hardware roots of trust like Trusted Platform Modules (TPMs) where available. This would look like the following:
This looks like a pretty standard setup, with the image containing the necessary applications needed to perform software development. It includes endpoint protection mechanisms such as malware protection, data loss prevention, and the components necessary to perform inventory and enforce policies across an organization’s endpoint systems.
This hardware inventory management system however, is not sufficient by itself. It still needs to have a way to verify against organization policy and trust parameters. This is where the “Trust Foundation” comes in. The “Trust Foundation” is a core connective tissue in an organization, this determines who and what are trusted across the organization, how they are trusted and what they are trusted to do. It consists of all aspects of managing trust, including a set of services, policies, and key material used to authenticate and authorize identities — both user and machine identities. Examples of this include OIDC, LDAP, and OAUTH protocols, plus identity management systems like Active Directory (for users) and Secure Production Identity Framework For Everyone (SPIFFE) and SPIRE, a SPIFFE runtime environment, which together provide an identity management system for machines.
Great! Secure Bank’s developers now have secure workstations. What about their development infrastructure? In most practices today, the developer Interactive Development Environment (IDE) is part of the developer’s workstation. One large question around this area is if code development tooling should be moved from running from the workstation to the development infrastructure — for example Visual Studio Server, or Gitpod. The idea here is that running the developer tools on an organization-controlled machine within a datacenter is much easier to secure than a workstation in the wild. With simpler endpoints, endpoint security becomes much easier.
No older posts
No newer posts