• Русский

Configure a basic set of security policies

Context

After the first analysis in CodeScoring.SCA, you usually get a lot of information about dependencies and vulnerabilities. A basic set of rules helps separate the most important cases from the general flow of results and makes it easier to understand what deserves attention first.

For VCS projects at the source stage, a practical starting point is to create three separate policies:

• one for vulnerabilities that already have a public exploit and a fix;
• one for dependencies with critical vulnerabilities;
• one for components that were published less than a month ago.

These rules help set priorities faster without overwhelming the team with noisy alerts or introducing hard blocks too early.

Why this starter set works

OpenSSF recommends prioritizing dependency risk instead of treating all findings as equal, and OWASP highlights the value of handling the most dangerous and actionable cases separately. CodeScoring research also shows that a useful starter set separates three different queues: vulnerabilities that are already exploited and already fixable, dependencies with critical vulnerabilities, and very young components that still need additional verification before wider use.

What you will get

By the end of this scenario, CodeScoring will contain three active policies for VCS projects at the source stage:

• a policy for vulnerabilities with a public exploit and a fixed version at the source stage;
• a policy for dependencies with critical vulnerabilities at the source stage;
• a policy for very young components at the source stage.

After a repeated SCA run, you will be able to see which of these rules already produce useful alerts.

Requirements

Before you start, make sure you have:

• access to CodeScoring with the Administrator or Security Manager role;
• at least one connected VCS project that can be rescanned with SCA;
• a clear decision on whether this starter set should be applied to all projects immediately or only to a pilot project first.

Steps

Step 1. Create a policy for vulnerabilities with an exploit and a fix

This rule helps surface not just any vulnerabilities, but the ones that are already practical to exploit and also have a clear remediation path.

1. Go to Settings -> Policies.
2. Click Create.
3. Fill in the policy context:
   • Name — for example, Exploit and fix;
   • Stages — source;
   • Level — choose the severity level that fits your process;
   • Is Active — enable it;
   • Blocker — keep it disabled.
4. If you want to roll the set out gradually, specify a pilot project in Projects. If the rule should apply to all active projects, leave Proprietors, Groups, and Projects empty.
5. In the default top-level conditions group with the AND expression, add:
   • Vulnerability has exploit;
   • Vulnerability has fixed version.
6. Click Create.

Why Blocker should stay off at first

For a starter set it is more useful to see what the rule really catches and how noisy it is before turning it into an enforcement point. That makes it easier to shape the process without stopping scans or everyday work too early.

After that, the platform will have a rule that creates alerts for the most actionable vulnerability cases in VCS projects.

Step 2. Create a policy for dependencies with critical vulnerabilities

Creating a separate rule for critical vulnerabilities helps move the most severe cases into their own review queue. For a starter set, this makes it easier to track them separately and avoid mixing them with lower-risk findings.

1. Open the policy created in the previous step.
2. Click Create a copy.
3. Change the main fields:
   • Name — for example, Critical vulnerability in a dependency;
   • Stages — keep source;
   • Is Active — keep it enabled;
   • Blocker — keep it disabled.
4. Remove the previous conditions.
5. In the default top-level conditions group, select the OR expression and add:
   • CVSS2 Severity = critical;
   • CVSS3 Severity = critical;
   • CVSS4 Severity = critical.
6. Click Create.

At this point, the starter set also includes a separate rule for dependencies that have at least one critical severity signal in one of the CVSS versions.

Step 3. Create an informational policy for very young components

This rule helps isolate dependencies that were published very recently. For a starter set, this is more useful than making the policy blocking right away, because the team gets a separate signal for additional verification of new packages and versions without mixing it with vulnerability handling or routine upgrades.

Why this rule should stay informational at first

For a starter set it is more useful to observe these components as a separate signal and understand how often they appear in your projects. Turning this rule into a blocker too early can interrupt routine workflows because of normal library updates before the team has agreed on how new versions should be reviewed.

1. In Settings -> Policies, click Create again.
2. Fill in the policy context:
   • Name — for example, Component younger than 30 days;
   • Stages — source;
   • Is Active — enable it;
   • Blocker — keep it disabled.
3. If you want a gradual rollout, specify a pilot project in Projects if needed.
4. In the default top-level conditions group, select the OR expression and add:
   • Dependency age (days) < 30;
   • optionally, a condition for dependencies where age information is missing.
5. Click Create.

If you want to refine the threshold later or extend the rule, the full list of supported criteria is described in policy setup.

What to keep in mind about dependency age

The platform determines the dependency publication date for supported ecosystems. Before rolling this rule out to all projects, it is better to validate it on a pilot project first and confirm that the criterion behaves as expected for your packages and sources.

After that, very recently published components start appearing in a separate alert stream, making it easier to review them before they spread widely across projects.

Step 4. Rerun the analysis and check the first alerts

Policies start working during analysis, so after configuring them it is worth verifying immediately that the source rules already participate in the process.

1. Open one of the projects to which the new policies should apply.
2. Click Run SCA on the project page.
3. Wait for the analysis to finish.
4. Open the Policy alerts section.
5. Check whether new alerts appear for:
   • vulnerabilities with an exploit and a fix;
   • direct dependencies with critical vulnerabilities;
   • very young components.

At this point, the starter set is already in use: all three rules produce alerts after analysis and separate the most important cases into different review tracks.

Result

The scenario is complete if:

• three active policies from this set are visible in Settings -> Policies;
• all three policies use the source stage and contain the expected criteria;
• the young-component policy uses the Dependency age (days) < 30 condition and remains non-blocking;
• after a repeated analysis, the first alerts for each policy type can be reviewed in Policy alerts.

After that, the platform already has a minimal set of guardrails that helps stop the riskiest components and focus the team on findings that matter first.

What next

• review triggered alerts;
• configure exceptions for acceptable cases;
• connect policy notifications;