Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


10:00 AM
Connect Directly
E-Mail vvv

3 Tips For Better Security Across the Software Supply Chain

It may sound look intimidating, but with a few tweaks to tools and processes already in use, it's not hard to get a head start on improving security posture of the software supply chain.

We all know the adage that a chain is only as strong as its weakest link, but it's easy to forget that this also applies to the software supply chain. Those who work with government or other highly regulated industries, or have customers that do, have likely been asked before about their software supply chain practices. And if they haven't, they should be prepared to answer when questions come up, because they will. 

Strengthening the security of the software supply chain can look intimidating on top of all of the other responsibilities security and IT teams are tasked with, but with a few tweaks to the tools and processes already in use, it's fairly easy to get a head start on improving security posture. 

Here are three ways to improve and support security in the software supply chain. 

Align Purchase and Management Workflows 
There are two big questions that must be answered first: Which tools and libraries are in use, and where did they come from? It's nearly impossible to properly secure the software supply chain without this knowledge.

Many software projects utilize specialized tools that may be commercially licensed or handled via credit cards or expense reports. While typically lower-volume or -value items get taken care of through the latter, these smaller purchases can become bigger issues later. Everyone validates their tools differently, and as such, the integrity of the supply chain can become compromised.

Although it may be a nuisance to switch payment processes over, it's better long term to ensure that the acquisition of tools and components critical to developers is done through the same purchasing processes as other IT assets. This makes it easier to track who requested and approved purchases and adds the forcing function of vetting each supplier with the same scrutiny. Having this visibility instills more confidence that the right pieces of software or components are acquired.

Tracking shouldn't simply stop at who approved purchase of a tool. If the capability is there, companies should track their developer tool and third-party component use in their asset management system. 

Monitor Developer and Build Machines
Equally important is looking at the machines inside an organization where development work is happening. Developers generally have complete admin access to their machine, even when they're part of the organization's managed computing environment. Build machines, however, are rarely managed, making it difficult to get a full view of the software development environment. 

In order to tighten up the supply chain, teams must change how they manage both developer and build machines. Leveraging system management tools, devices can regularly be audited for the software installed and the processes running on them. With this information, IT can confirm that the development and build work is being done under the expected conditions. 

Another supply chain weakness related to build machines is the use of shared, well-known accounts. It is a good idea to stop this practice and use the existing account directory for authentication to these machines in order to improve logging and security. Privilege management tools are often useful here to allow individuals to assume the role of a build user after logging in as themselves.

Stay on Top of Patching
Once developer and build machines start to have some management processes in place, the next step is ensuring machines are practicing basic security hygiene by ensuring that: 

  • The operating system is fully patched.
  • Antivirus or anti-malware software is installed and running.
  • Definitions and software components are all up to date.

These practices help ensure the integrity of software being built, however, these are not one-time projects. Implementing this correctly may require a phased approach. First, the inventory data can be used to identify compliance issues on developer and build machines and notify the owners. Then, IT can choose to manage updates on a small subset of machines or on a duplicate environment. Finally, IT will likely find they've built enough confidence with the development team that they can actively manage all machines. Through this entire process, it is important to be clear about the expected timeline for bringing machines into compliance with patching and other security standards.

When evaluating supply chain security, IT can be a valuable partner. By continually evaluating the processes and tools used and adapting them to ensure they meet the needs of development organizations, the software supply chain can be tightened up and properly secured. 

These steps are not comprehensive for securing the software supply chain, but they are a way to take advantage of the existing capabilities in an organization and for IT to get started in their journey to increase security.

Related Content:



Register now for this year's fully virtual Black Hat USA, scheduled to take place August 1–6, and get more information about the event on the Black Hat website. Click for details on conference information and to register.

Matthew Lewinski has been developing endpoint management solutions for over 14 years. He is currently a Distinguished Engineer with Quest Software, where he leads DevOps and Security programs for the KACE Unified Endpoint Management business. Matthew has an M.S. in Software ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Threaded  |  Newest First  |  Oldest First
COVID-19: Latest Security News & Commentary
Dark Reading Staff 10/13/2020
Where are the 'Great Exits' in the Data Security Market?
Dave Cole, Cofounder and CEO, Open Raven,  10/13/2020
Overcoming the Challenge of Shorter Certificate Lifespans
Mike Cooper, Founder & CEO of Revocent,  10/15/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-10-19
Sprecher SPRECON-E firmware prior to 8.64b might allow local attackers with access to engineering data to insert arbitrary code. This firmware lacks the validation of the input values on the device side, which is provided by the engineering software during parameterization. Attackers with access to ...
PUBLISHED: 2020-10-19
In JetBrains YouTrack before 2020.2.10514, SSRF is possible because URL filtering can be escaped.
PUBLISHED: 2020-10-19
A DNS rebinding vulnerability in the UPnP MediaServer implementation in Freebox Server before 4.2.3.
PUBLISHED: 2020-10-19
A ictexpertcsvdownload expression language injection remote code execution vulnerability was discovered in HPE Intelligent Management Center (iMC) version(s): Prior to iMC PLAT 7.3 (E0705P07).
PUBLISHED: 2020-10-19
A perfaddormoddevicemonitor expression language injection remote code execution vulnerability was discovered in HPE Intelligent Management Center (iMC) version(s): Prior to iMC PLAT 7.3 (E0705P07).