Heisenberg is an open-source tool that checks the health of a software supply chain. It analyzes dependencies using data from deps.dev, Software Bills of Materials (SBOMs), and external advisories to measure package health, detect risks, and generate reports for individual dependencies or entire projects.
“We wanted a practical way to catch and block risky changes before they reached the main branch,” Max Feldman, Head of Application Security at AppOmni, told Help Net Security. “The turning point was when we stopped treating SBOMs as static paperwork and started using them as live, actionable data.”
“We built an automated, lightweight check that focuses on what changed in each pull request (PR). If a dependency is new, unhealthy, flagged by an advisory, or has no verifiable history, it is surfaced right where developers are already working, in the PR. And when a new campaign hits the ecosystem and everyone asks, ‘Are we affected?’, we want answers from our SBOMs within minutes instead of spending days digging manually.”
Beyond traditional SCA tools
Most software composition analysis tools only flag known vulnerabilities with CVEs. Heisenberg goes further by identifying suspicious packages based on factors such as age, maintenance, and deprecation status. This helps teams catch problems like potential malware in npm packages before they are disclosed. It can comment directly on pull requests to stop risky code from being merged or be used later to investigate whether a dangerous package is already in use.
Lightweight and non-intrusive, Heisenberg turns SBOMs into a practical defense tool. It helps detect supply chain threats early without slowing down development.
Catching hidden risks
“Let’s take a look at something less obvious than deliberately poisoned or malicious packages,” said Yevhen Grinman, Lead Security Engineer at AppOmni. “Think about typosquatting when a malicious actor uploads a package very similar in name to the real package and posts it on PyPI or npm repos. A developer can accidentally mistype the name of the package and introduce a malicious package to the supply chain because of the typo. Traditional SCA may detect this in retrospect if the package ends up being officially flagged for a vulnerability. Or the package may end up living in the codebase for a long time and silently doing something bad to your project. However, Heisenberg will flag something like this right away because a typosquatted package will most likely have a low or unknown health score, questionable provenance, and non-existent dependents. This is just one of many examples where Heisenberg can help instantly vs. traditional SCA,” Grinman noted.
Four CLI modes for different use cases
Grinman explained that Heisenberg ships with four Command Line Interface (CLI) modes:
- SBOM: This generates the per-repo SBOMs. It creates a stripped-down version of SBOM (per repo or multiple repos) that becomes our query surface. It’s intentionally boring because boring is easy to parse, diff, and automate. This is mostly a background mode that is used by other modes, but it can also be handy during investigations.
- Check: This is the individual package deep dive. Backed by the deps.dev API, check pulls in project metadata (scorecard/maintenance, stars/forks, dependents, advisories), detects fresh publishes (<24h), and prints cross-reference links (deps.dev, Snyk Advisor, Socket). Additionally, It flags deprecated/inactive packages. If deps.dev lacks data, it falls back to the GitHub API and the npm/PyPI registries. Under the hood, it also computes a Custom Health Score that softens extremes by blending popularity, maintenance, dependents, and vuln signals, putting the most weight into security of the project. Finally, for npm packages, it can detect if there are postinstall scripts, which could be an indication of potential malware.
- Bulk: This fans out checks across all our SBOMs. The bulk runner parallelizes calls to check over every SBOM row and writes a consolidated report with fields like health score, security advisories, deprecated, and others. Think of it as our portfolio scan that creates visibility into our overall software supply chain health.
- Analyze: Helps find packages across SBOMs fast. Think of it as an “are we affected?” button. Feed it a comma-separated list or a text file of package names, and it returns the SBOM rows where they appear.”
What’s next for Heisenberg
Grinman said the team is expanding Heisenberg’s capabilities with several new features and integrations. Support for additional package managers is coming soon, along with more control over the tool’s feedback loop.
He explained that users can already accept certain risks in a pull request by commenting to mute specific Heisenberg findings. The team also plans to let organizations maintain an allow-list for internal packages, which often lack public metadata and are therefore flagged by default. “We want engineers to be able to create an allow-list to mute some of those findings,” Grinman said.
Deployment and integration are another focus. The team intends to Dockerize Heisenberg to make it easier to deploy and integrate into CI/CD pipelines. They are also working on Policy-as-Code support so that security teams can define and enforce their own risk and maintenance thresholds.
Grinman added that they’re exploring how to use AI to improve risk detection. Many indicators, such as a package’s commit history or documentation quality, can be subjective. “We aim to use AI to analyze these signals and provide more accurate input into Heisenberg’s Custom Health Score,” he said. The team is also watching for new supply chain risks tied to machine learning and plans to extend Heisenberg to detect issues related to MCP servers and open-source models.
Heisenberg is available for free on GitHub.
Must read:
Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!
