Lockfiles are our friends
I was out for a walk earlier this afternoon, listening to an episode of The Pragmatic Engineer Podcast that had a particular focus on security. It seemed to pre-date the recent spate of supply chain attacks but got me into a mindset of, “How can we protect development systems from compromised dependencies?”
During one of my rest breaks to sit on a park bench for a few minutes, I made a little note to myself to propose taking a checksum of each trusted dependency and storing that somewhere immutable for later reference on build systems. That way we can have greater confidence that the artifacts being included in a build have not been compromised.
It turns out that what I was getting ready to set up is essentially what lockfiles already do.
As far as I can tell, NodeJS and Python build systems have lockfiles as a normal expectation of their build systems, but it is not something that I have seen being applied much in Java codebases.
What may have originally been intended to ensure consistent builds across environments could also provide an additional layer of security, by early detection of when an anomaly has been introduced.
I can see that this form of anomaly detection would be useful in situations where an existing version of an artifact has been replaced by something different in the supply chain, so it would not offer protection against a freshly created compromised version.
Awareness is key
I can’t recall the specific project or language, but I can recall having to update the checksum values in lockfiles to make software build on my development machine. This should not be considered as a normal edit if there is no corresponding version bump involved.
To apply an analogy from The Matrix, seeing a checksum change in a lockfile should be treated like Neo’s Déjà vu moment – a sign that something has been changed, that may lead to danger ahead.
Scanning on Dependency Proxy Servers
Thinking aloud here, I can envisage a future where there will no longer be free-for-all servers that host open source software libraries for given languages. Instead, companies will be formed that specialise in offering a service that obtains the source code of each library, analyses for known and potential security issues, builds up any secure artifacts and makes those available to subscribers.
Once the built artifacts are in place, the hosting service will continously monitor for reports of new vulnerabilities and / or apply its own fresh scans based on updated models, feeding downstream as and when incremental improvements are available.
The chicken or the egg
In certain sectors and industries the requirements to provide Software Bills Of Materials will end up driving software developers to keep track of dependencies anyway, so it will be interesting to see what comes first – the SBOM or the lockfile.
Leave a Reply