If you develop software for governments or other highly regulated industries, you’ve most likely been asked about your software supply chain practices. Even if you aren’t developing directly for those customers, it is likely that one of your customers does, so it is only a matter of time before questions about the integrity of your software come up.

Building assurance in the security of your software supply chain can be a daunting task, but IT can help kickstart the process by adapting existing systems management tools and processes.

 

 

Here are four ways to get started:

1. Leverage existing purchasing workflows  

A secure software supply chain begins with a clear and accurate understanding of the inputs to your organisation: what you have and where you got it from. Most software projects include the use of third-party dependencies, some of which could be commercially licensed. Developers also often require specialised software tools to perform their job. These aren’t necessarily large purchases, so some organisations may handle some of the lower-volume or lower-value items with credit cards or expense reports. These credit card purchases are potential issues when considering the integrity of the software supply chain, because everyone will do (or more importantly, not do) different validation steps.

Since these tools and components are critical inputs to your software supply chain, it is much better to handle their acquisition through the same purchasing process as other IT assets. You will have better tracking of who requested and approved the purchase. You’ll also vet the supplier with the same scrutiny as every other supplier you use. These will lead to better confidence that the right piece of software or component was acquired.

 

2. Make use of asset management systems

 If you have a robust purchasing process, it probably also feeds data into an IT asset management system. It is a good idea to also track these developer tools and third-party components in the asset management system. If you can do so, it makes sense to add a custom asset type for these purchases so that you can consistently track additional metadata about them. For example, if a software library is downloaded from a website, you may want to track the date it was downloaded, the URL it was downloaded from, the version that was downloaded, and any checksums that would allow verification of the download in the future. The asset management system thus serves an important role as both documentation and audit for the software supply chain.

Having this kind of data in your asset management system can also pay off when it comes to managing updated components. If you have an existing process that generally tracks updates to software that you purchase, you can now also use that process to make sure that you have timely notification of updates to your development tools and third-party components. You can also use the asset management data to quickly identify affected applications if you receive information about a vulnerability in a third-party component.

 

3. Track development and build machines

Sticking with the theme of accurately tracking different aspects of your software supply chain, let’s shift focus to the machines inside your organisation where development work is done. In my experience, developers generally have full administrative access to their machine, whether they are part of the organisation’s managed computing environment or not. Build machines, on the other hand, seem to nearly always be unmanaged. These conditions make it challenging to get a complete picture of the environment in which the software is developed.

In order to build confidence in the software supply chain, change is needed. Both developer machines and build machines should at least be partially managed. System management tools can provide accurate inventories of the software installed on the device and the processes that are running on it. This information can be useful in confirming that the development and build work is being done under expected conditions. At the start, it may be necessary to separate the policies and configuration for the developer and build devices to limit it to just this kind of inventory collection, to build confidence that the system management tool won’t affect the development process.

Additionally, you may want to investigate using a privilege management tool that has centralised logging and reporting to provide better audit capabilities for those developers that do require local administrative access. In this way, the developer still has the access required to do their job while improving the overall assurance of the software supply chain.

Build machines also frequently have shared, well-known accounts. This is generally both a side effect of the fact that they are unmanaged and because it is more convenient. It may be a good idea to stop this practice and use your existing account directory for authentication to these machines, to improve logging and security. Privilege management tools may also be useful here to allow individuals to assume the role of a build user after logging in as themselves.

 

4. Stay on top of patching

Once your developer and build machines are under management, a natural next step in improving your software supply chain security is making sure those machines practice basic security hygiene: Is the operating system fully patched? Is there anti-virus or anti-malware software installed and running? Are the definitions up to date? Are other software components up to date? These questions may make development staff a bit uneasy, as changes to these seemingly unrelated components could still have an adverse effect on the stability of the software they’re working on. However, keeping all these things up to date is an important part of building high-integrity software.

Implementing this step may require a phased approach. First, you might simply use the inventory data to identify out-of-compliance issues and notify the owners. Next, you may choose to push some updates to a small subset of machines or on a duplicate environment. Finally, you may find that you have built enough confidence with the development team that you can actively manage these aspects of all their machines. The schedule for patching and software updates may end up being different than the rest of the organisation, but in the end, you will want to set hard deadlines for compliance.

 

In conclusion

 IT can help build assurance in the security of the software supply chain by adapting some of their existing processes. First, always use your existing purchasing process for development tools and licensed components. Second, make sure these purchases are tracked in your asset management tool. Third, use a systems management tool to get a handle on the configuration of your development and build environments. Finally, work towards using your systems management tools to ensure that those environments are kept up to date.

These steps are not a complete solution for software supply chain security, but they are a way to take advantage of your organisation’s existing capabilities and give your team a head start down that path.