When a new software vulnerability is found, it's surprisingly hard to tell if your past product releases ever included the compromised package. Answering 'Were we affected?' requires reconstructing precisely what was installed during each specific build, as current dependencies often don't tell the whole story.
Welcome to the WondTech blog! Have you ever heard about a software package vulnerability and wondered: 'Are we affected by this?' That sounds like a simple question, right? But in the world of software development, answering it is much harder than you might think, and this directly impacts your software's security and your products. The problem is that simply looking at your project's current list of dependencies isn't enough to figure it out. The vulnerable version of a package might have appeared and disappeared quickly. Tools like Renovate might have already replaced it with a newer version. Even the 'lockfiles' that record specific package versions can change after a particular software release. Plus, Docker layers or CI caches might reuse components that no longer appear on your project's main branch. In short, a clean scan today tells you very little about the artifact you built yesterday. This makes responding to software supply-chain security incidents a 'reconstruction problem.' The important unit isn't your code repository as it exists now; it's a specific artifact produced by a particular build process, using a definite set of resolved packages from that time. Consider what happened on August 4, when Aikido disclosed that a maintainer account behind Keyv-related packages had been compromised. Malicious releases were used to install harmful code designed to steal credentials. Such incidents move quickly and can be over before your team can even determine if any released artifact ever contained the bad version. So, what do we need? We need a tool that can accept a lockfile, a build timestamp, and information about the final artifact. It would then reconstruct exactly what was used in that specific build. This tool should produce a report organized around images, services, and customer-delivered versions, with clear evidence for each conclusion. For example, a lockfile entry with resolved and integrity fields is direct evidence, while a registry publication window combined with a version range might only be an inference. Distinguishing between these types of evidence is crucial because the results could lead to expensive or irreversible decisions, such as isolating a service or rotating credentials. Keeping your software secure requires a clear view of what was used at every step of the build process.
