Two complementary controls
Software composition analysis (SCA) identifies risks in your dependencies. mShield applies your policies to package requests before serving an artifact. Together, they help teams control new downloads and review software already in use.
mShield
Package request → policy decision → allow or block.
Controls downloads routed through mShield and records the outcome.
SCA
Dependency inventory → risk findings → remediation.
Checks manifests, lockfiles, or artifacts, depending on the tool and workflow.
SCA tools may also block pull requests or builds. The distinction is the control point: mShield enforces policy on the live package request.
Side by side
| SCA scanner | Install-time policy (mShield) | |
|---|---|---|
| When it acts | During development, in CI, or on a schedule; depends on the tool | During the request, before the artifact is served |
| What it reads | Lockfiles, manifests, built images, SBOMs | The live package request: name, version, ecosystem |
| Output | Findings, remediation guidance, or a workflow gate | An allow or a refusal, plus a record |
| Effect on a bad package | May prevent a merge or build; installed artifacts may need cleanup | The blocked artifact is not served |
| Coverage | Dependencies discoverable from the scanned inputs | Everything that comes through the gate, including ad-hoc and one-off installs |
| Blind spot | Anything installed outside a scanned manifest; the window between landing and the next scan | Anything installed off the gated path; what is already in the tree |
| Failure mode | A backlog nobody has triaged | A blocked build someone has to unblock |
| Who feels it | AppSec, in the queue | The developer, immediately, with a reason |
Why the download is a useful control point
Install scripts can run before a later scan
Some packages execute code during installation. Blocking a request that violates policy prevents that artifact from being served through mShield.
Ad-hoc installs also need coverage
Global tools, experiments, and notebook installs may sit outside your usual repository scans. mShield evaluates these requests when they use the configured route.
New findings still need follow-up
A package can become known as vulnerable or malicious after installation. Keep SCA and remediation workflows for dependencies already present. Neither request-time policy nor advisory matching guarantees detection of unknown malware.
How they divide the work
A sensible split for a team running both:
- The gate holds the line on what is clearly not allowed. Known-malicious packages, licenses you cannot ship, severity thresholds your organisation has already agreed. These are decisions nobody wants to make again per ticket, so they belong in policy.
- The scanner owns inventory and drift. What is in the tree, what became vulnerable after it was installed, what a new advisory implies for what is already running. A gate says nothing about a package that was fine when it arrived.
- Warning mode is how you introduce a policy. Run a new policy in allow-with-warning against real traffic, read what it would have stopped, and only then switch it to block. Your scanner's backlog is a good source of candidate rules: the finding you keep re-triaging is usually a policy you have not written yet.
- The record is shared ground. Every decision, allowed or refused, is kept. That is the data that shows whether a policy is doing useful work or just generating unblock requests.
Questions worth asking of either tool
- What happens to a malicious package published today, installed today?
- Where exactly does it act — and what percentage of your installs go through that point?
- When it refuses or flags something, does the developer get an answer, or a queue?
- What is the rollback if it is wrong, and how long does it take?
- Is there a record of what was allowed, or only of what was flagged?
mShield's answers are in how it works and what it does not do. Review both when planning coverage.