How do organisations decide whether to block dependencies by severity or by malicious classification?

Use severity thresholds for broader risk management, but use malicious classification for explicit trust decisions. Severity reflects potential impact if a weakness is exploited, while malicious status indicates the package itself is unsafe to allow. Mature teams combine both controls, then scope enforcement by project, tag, or workflow stage so blocking stays precise and operationally usable.

Why This Matters for Security Teams

Dependency policy is not just a build-time preference. It determines whether security teams treat an issue as a risk to manage or a package to refuse outright. Severity-based blocking is useful for controlling exposure across large software portfolios, while malicious classification is a stronger trust signal that the artifact, maintainer, or distribution path should not be accepted. The difference matters because one drives prioritisation and the other drives denial.

Teams often blur the two and end up with controls that are either too permissive or too disruptive. A high-severity vulnerability may be acceptable in a short-lived internal tool with compensating controls, but a malicious package should not be admitted simply because its current severity score is low. That is why policy needs to distinguish exploitability from trustworthiness and tie each to a different enforcement decision. NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful reference point for aligning software supply chain decisions with broader access and integrity controls.

In practice, many security teams encounter this distinction only after a compromised dependency has already been allowed into a trusted pipeline.

How It Works in Practice

Most organisations implement two layers of enforcement. The first layer uses severity thresholds from vulnerability intelligence, such as critical or high findings, to decide when builds should fail or when exceptions need approval. The second layer uses malicious classification from supply chain or repository intelligence to block the package regardless of severity, because the issue is not just weakness but active distrust.

This separation is important because severity and maliciousness answer different questions. Severity asks how much harm could result if a weakness is exploited. Malicious classification asks whether the dependency should be treated as unsafe to consume at all. A package can be low severity yet malicious if it contains a backdoor, typosquats a popular library, or shows clear indicators of compromise. It can also be high severity without being malicious, which may justify patching, pinning, or compensating controls rather than immediate rejection.

• Use severity to drive remediation timelines, exception handling, and risk acceptance decisions.
• Use malicious classification to stop ingestion, quarantine artifacts, or require manual trust review.
• Scope both rules by repository, environment, release stage, or package namespace so enforcement matches operational risk.
• Log the exact reason for the block so developers can tell whether the issue is exploitability, provenance, or explicit malicious intent.

For software supply chain governance, current guidance suggests pairing policy enforcement with provenance and integrity checks, not relying on a single score. The OWASP Supply Chain Security Top 10 is useful for framing where dependency trust fails, while CISA’s Known Exploited Vulnerabilities Catalog helps teams distinguish urgent remediation from routine hygiene. These controls tend to break down when dependency policy is enforced globally without environment context because developers then either bypass the pipeline or accumulate unreviewed exceptions.

Common Variations and Edge Cases

Tighter blocking often increases developer friction and exception workload, requiring organisations to balance supply chain assurance against delivery speed. There is no universal standard for this yet, so teams usually adopt a tiered model that reflects their risk appetite and release maturity.

One common variation is to treat malicious classification as an absolute deny rule only in high-trust or production pipelines, while allowing security review in lower-risk branches or sandbox environments. Another is to use severity thresholds that vary by application criticality, so a customer-facing service has stricter cutoffs than an internal prototype. This is where workflow stage matters: a package that is acceptable in a development branch may still be blocked from release if its risk posture changes.

Edge cases arise when signals conflict. A package may be flagged as malicious by one source and merely vulnerable by another. In that situation, best practice is evolving toward evidence-based trust decisions: verify provenance, inspect maintainer history, compare hashes, and check whether the package has been revoked or superseded. Some teams also add human review for new publishers, freshly created namespaces, or packages that suddenly change ownership. The important point is to keep severity and malicious classification separate in policy logic, even if both appear in the same security dashboard.

For organisations with regulated software distribution or strong integrity requirements, the NIST software supply chain security guidance is a practical reference for how blocking, provenance, and verification fit together. These controls tend to break down when teams rely on a single universal rule across all repositories because the resulting false positives are high enough that enforcement pressure shifts from policy to exception handling.

Related resources from NHI Mgmt Group

• How should organisations decide whether to block a release for an SCA finding?
• How should organisations decide whether to keep using traditional MFA?
• How should organisations decide whether ABAC is ready for production IAM use?
• How can organisations decide whether SPIFFE is enough for their environment?