Open-Source · Software Composition Analysis

Open-source risk, without the noise.

Most of what your app runs is code your team never wrote. It comes from open-source packages, and those packages pull in other packages you have never heard of. A normal scanner lists a vulnerability for every one of them. Moolé does something simpler and smarter. It checks whether your code actually calls the broken part, and only flags the ones that can reach you.

01 · The problem

You did not write most of your app.

In a modern application, it is normal for 80% or more of the shipped code to be open-source. You install a handful of packages, and each of those quietly brings along dozens more underneath. A traditional scanner reads that whole pile, matches every package against a list of known flaws, and grades each one by a generic severity score. The result is a wall of "critical" findings. But a critical flaw in a function your code never runs cannot hurt you. So teams spend their week chasing red badges that were never a threat, while the one that matters sits in the same undifferentiated list.

your-app the code you own express direct dependency report-utils direct dependency image-tools direct dependency mime-types transitive · clean safe-buffer transitive · clean lodash 4.17.4 transitive CVE · reachable handlebars 4.0.1 transitive · never called CVE · present, not reachable minimatch 3.0.2 transitive · never called CVE · present, not reachable
path your code actually calls vulnerable and reachable vulnerable but never called

Reachability is the whole trick. Three packages here carry a "critical" CVE. Only lodash sits on a path your code actually runs, so it is the only one that can be exploited. The other two are shipped in your build but no line of your code ever calls them, so they cannot do anything. A generic scanner would page you for all three. Moolé shows you the one.

A list of every known flaw.
Or the few you actually call.

02 · How it works

Three parts, one honest answer.

SCA in Moolé is not a single scan. It is three jobs working together: find everything you depend on, decide what is genuinely worth your time, and give you the paperwork to prove it.

01

Discover

Auto-scans your repositories and maps the full dependency graph, including the hidden transitive packages your direct dependencies pull in. It finds manifests and lockfiles on its own, so nothing you actually ship gets missed.

The whole tree, not just the packages you typed.
02

Prioritize

Ranks findings by real business impact using runtime reachability. It de-duplicates the same CVE showing up in ten places, and separates code that reaches production from packages that only exist in your dev and test tooling.

Production risk first. Dev and test noise last.
03

SBOM & Governance

Generates an audit-ready Software Bill of Materials in SPDX and CycloneDX, tied to a specific build so you know exactly what shipped. It detects package licenses and enforces org-level policy across every repo.

Know what is in the box, and prove it.
03 · A real example

Same CVE. Two very different weeks.

Here is the exact situation from the graph above, the way each side of the industry handles it. One package is present but never called. One is genuinely reachable. Watch what happens to your sprint.

yarn.lock · what other tools seethe old way
"lodash@4.17.4": version "4.17.4" # CVE-2019-10744 · CRITICAL # (prototype pollution in defaultsDeep) your code: import { get } from "lodash" # defaultsDeep is never imported scanner verdict: CRITICAL. block the build. page on-call. file the ticket. team spends a sprint on a flaw nothing in this app runs.
moolé · what actually matterswith Moolé
lodash@4.17.4 · CVE-2019-10744 vulnerable fn: defaultsDeep your code calls it? no reachable: no → severity downgraded → no action needed express → cookie@0.3.1 · CVE-... vulnerable fn: parse() your code calls it? yes reachable: yes → fix PR opened → safe upgrade to 4.17.21

One of these packages was never a threat, and Moolé says so plainly instead of making you prove it. The other is real, so Moolé does the boring part for you and opens the upgrade as a pull request.

04 · In your workflow

It shows up where the work happens.

Findings live in the pull request and the pipeline, not in a portal your team forgets to open. Four ways Moolé fits into a normal day.

01

PR enforcement

When a change adds or bumps a dependency into risky territory, Moolé gates it right on the pull request, so a bad package never quietly merges to main.

The check runs before the code lands.
02

Automated remediation

For reachable issues it opens a safe upgrade as its own pull request, and bundles related bumps together so you review one clean change instead of ten.

The fix arrives as a PR you can just merge.
03

Portfolio view

Rolls up findings across hundreds of repositories into one place, so a platform or security lead can see where real dependency risk actually sits.

Every repo, one honest scoreboard.
04

License detection

Reads the license of every package it finds and flags the ones that break your policy, so a copyleft surprise does not reach production unnoticed.

Legal risk caught next to security risk.

Other tools hand your team homework.
Moolé hands them a merge button.