The threat to software supply chains appears to be worsening in the wake of two substantial breaches. First, Slack discovered suspicious activity on its private GitHub repository for building software that consisted of a limited number of employee tokens being stolen and misused to gain access to an externally hosted repository. An unidentified threat actor had also downloaded private code repositories, but neither Slack’s primary codebase nor any customer data were included in the downloaded repositories.
Then CircleCI, a provider of continuous integration/continuous delivery (CI/CD) used by many companies to build and deploy applications, is warning customers to immediately rotate all secrets — think passwords, API keys, SSH keys, configuration files, OAuth tokens, etc. — stored on the platform in the wake of a security incident under investigation at the company.
It’s not clear what impact these events might ultimately have, but in the wake of similar breaches involving LastPass and SolarWinds it’s apparent there is a heightened awareness of the need for better software supply chain security. While each of these incidents is unfortunate, the fact they are being discovered and disclosed in a timely fashion may actually be a sign of meaningful progress.
Adopt best practices to secure software supply chains
Not too long ago, the odds these types of breaches might be discovered were low. There’s still a lot of debate over how best to secure software supply chains, but progress is clearly being made. The trouble is all this focus on software supply chains tends to encourage more cybercriminals to attack them. No one, of course, knows for sure how compromised software supply chains are, but there is more scrutiny being applied than ever. Some software supply chains might have been compromised for years without anyone knowing.
The most important thing is for application developers and cybersecurity professionals to develop a working relationship. The biggest barrier to the adoption of best DevSecOps practices required to secure software supply chains remains largely cultural. For more years than anyone cares to admit, many developers have viewed cybersecurity as a hindrance to application development that needed to be overcome or circumvented rather than being a core aspect of a quality assurance process. The total number of vulnerabilities that exist in applications running in production environments could likely be measured in the billions.
Developer and cybersecurity professional opportunity
The important thing to remember, however, is that not all those vulnerabilities are equally severe. One of the reasons there is so much distrust between application developers and cybersecurity teams is that the latter have historically tended to create lists of vulnerabilities that need to be patched without much context. Developers torn between writing new code and patching old code resent lists of vulnerabilities that, once investigated, turn out to not have any effect on the application because of the way code has been constructed or deployed. Worse yet, when it’s discovered, the odds that vulnerability will ever be exploited turn out to be, at best, remote.
Fortunately, a new spirit of détente and cooperation is in the air between developers and cybersecurity professionals. Rather than viewing each other with suspicion, there is now a real opportunity to change the nature of the dialogue in a way that benefits all concerned. Like any negotiation to end a conflict, it will, as always, require someone to be determined enough to make the first move.
