rorixrorix
dashboard →
Back to blog
|Rorix Team

How to Roll Out Dependency Scanning in CI Without Creating Alert Fatigue

guideci-cdpolicy
A software delivery pipeline progressing through four security gates

The fastest way to make a security check irrelevant is to turn it on as a required gate before anyone understands its output.

The first run finds years of accumulated dependencies. Pull requests fail for issues they did not introduce. Developers discover suppressions, rerun jobs until they pass, or route around the check. The scanner is technically installed and operationally ignored.

A better rollout treats trust in the signal as part of the implementation.

Phase 1: Learn the Baseline

Run the scanner against the default branch without blocking merges. Review the findings with the people who own the applications.

Your first pass should establish:

  • how many production projects are in scope;
  • which findings are direct versus transitive;
  • which target frameworks and deployment artifacts are affected;
  • which vulnerabilities have a safe upgrade path;
  • which packages or projects are not actually shipped;
  • where ownership is unclear.

Fix configuration problems now. A scan of generated examples, test fixtures, or retired projects produces noise that no severity threshold can solve.

Phase 2: Define What Must Stop a Pull Request

A merge gate should represent a decision the team has already made. Start with a narrow policy for risks everyone agrees are unacceptable.

For example:

version: 1
policies:
  max-severity: critical
  fail-on-typosquat: true

Avoid copying a strict policy from another organization without understanding its staffing, exposure, and current backlog. A rule that is routinely bypassed is weaker than a smaller rule that is consistently enforced.

Phase 3: Gate Changes, Not History

The pull request author should own risk introduced or worsened by the pull request. Historical findings should remain visible and assigned, but they should not make an unrelated documentation change fail.

This distinction gives the check a clear meaning:

pass  = this change stays within the agreed security baseline
fail  = this change introduces or regresses a policy violation

Teams can still run scheduled full scans against the default branch to track the complete exposure as new advisories are published.

Phase 4: Make Failures Actionable

When the check fails, report:

  1. the affected package and resolved version;
  2. the project and target framework;
  3. the path from a direct dependency to the finding;
  4. the policy rule that failed;
  5. a safe version or remediation direction, when known.

The result should be understandable from the pull request. Requiring every developer to search a separate dashboard makes the feedback slower and easier to ignore.

SARIF output can also place findings in the repository's security workflow:

rorix scan --format sarif --output results.sarif

See the scan command reference for CI-oriented output and exit codes.

Phase 5: Tighten With Evidence

After the team has operated the first policy, inspect what happened:

  • How often did the check fail?
  • How many failures represented real, newly introduced risk?
  • How long did remediation take?
  • Which exceptions expired without review?
  • Are certain teams or dependency families repeatedly affected?

Use those answers to tighten severity thresholds, add license controls, or establish response targets. Change one dimension at a time so the impact remains visible.

Keep the Control Healthy

Dependency scanning is not finished when the workflow file merges. Assign ownership for scanner upgrades, policy changes, exception review, and failures in the scanning service itself.

Test the gate periodically with a controlled fixture or policy change. A permanently green check may indicate a clean repository—or a job that stopped scanning the intended projects months ago.

Finally, keep discovery and enforcement distinct. A scheduled scan can be broad and investigative. A pull request gate should be fast, stable, and tied to an explicit decision.

The best security check is not the strictest one you can configure today. It is the one your team trusts enough to keep enabled while you steadily raise the baseline.

Related guides