You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/assets/demo/fstec-sbom-demo.en.html
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -69,7 +69,7 @@
69
69
{
70
70
type: "card",
71
71
title: "A manifest-only run may be incomplete",
72
-
body: "If the manifest does not expose transitive dependencies, this run does not provide the full component list. In such ecosystems dependency resolution in the environment is recommended for a complete inventory."
72
+
body: "If the manifest does not expose transitive dependencies, this run does not provide the full component list. A complete inventory requires either a lock file or dependency resolution in a prepared project environment."
73
73
},
74
74
{
75
75
type: "command",
@@ -94,7 +94,7 @@
94
94
{
95
95
type: "card",
96
96
title: "What changed after resolve",
97
-
body: "The agent used the specified <code>pip</code>, added the <code>pip freeze</code> result as <code>codescoring_pip_for_freeze</code>, saved the scan to a CLI project, and produced a local <code>bom-local.json</code>."
97
+
body: "The agent used the specified <code>pip</code>, added the dependency resolution result as <code>codescoring_pip_for_freeze</code>, saved the scan to a CLI project, and produced a local <code>bom-local.json</code>. This mode should be run only in a controlled project environment, otherwise extra packages can end up in the SBOM."
Copy file name to clipboardExpand all lines: docs/assets/demo/fstec-sbom-demo.html
+2-2Lines changed: 2 additions & 2 deletions
Original file line number
Diff line number
Diff line change
@@ -69,7 +69,7 @@
69
69
{
70
70
type: "card",
71
71
title: "Обычного запуска может быть недостаточно",
72
-
body: "Если манифест не раскрывает транзитивные зависимости, такой запуск не даёт полного перечня компонентов. Для качественного инвентаря в таких экосистемах рекомендуется разрешение зависимостей в окружении."
72
+
body: "Если манифест не раскрывает транзитивные зависимости, такой запуск не даёт полного перечня компонентов. Для качественного инвентаря нужен либо lock-файл, либо запуск с разрешением зависимостей в подготовленном окружении проекта."
73
73
},
74
74
{
75
75
type: "command",
@@ -94,7 +94,7 @@
94
94
{
95
95
type: "card",
96
96
title: "Что изменилось после resolve",
97
-
body: "Агент использовал <code>pip</code> по указанному пути, добавил результаты <code>pip freeze</code> как <code>codescoring_pip_for_freeze</code>, сохранил анализ в CLI-проекте и сформировал локальный <code>bom-local.json</code>."
97
+
body: "Агент использовал <code>pip</code> по указанному пути, добавил результат разрешения зависимостей как <code>codescoring_pip_for_freeze</code>, сохранил анализ в CLI-проекте и сформировал локальный <code>bom-local.json</code>. Такой режим стоит запускать только в контролируемом окружении проекта, иначе в SBOM могут попасть лишние пакеты."
body: "In this example, the Johnny Agent saved an SBOM, prepared `junit.xml`, and returned code `1` because the policies found issues that need attention."
162
+
body: "In this example, the Johnny Agent saved an SBOM, prepared `report.sarif`, and returned code `1` because the policies found issues that need attention."
Copy file name to clipboardExpand all lines: docs/tutorials/basic-security-policies.en.md
+32-36Lines changed: 32 additions & 36 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,19 +6,25 @@ title: "Configure a basic set of security policies"
6
6
7
7
## Context
8
8
9
-
After the first analysis in CodeScoring, you usually get a lot of information about dependencies and vulnerabilities, but without policies it is still just a list of findings. 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.
9
+
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.
10
10
11
-
For a practical starting point, three rules at the `source` stage are enough: separately track vulnerabilities that already have a public exploit and a fix, highlight critical direct dependencies, and surface components that were published less than a month ago. This reduces risk quickly without turning the first rollout into a noisy setup or introducing hard blocks too early.
11
+
For VCS projects at the `source` stage, a practical starting point is to create three separate policies:
12
+
13
+
- one for vulnerabilities that already have a public exploit and a fix;
14
+
- one for direct dependencies with critical vulnerabilities;
15
+
- one for components that were published less than a month ago.
16
+
17
+
These rules help set priorities faster without overwhelming the team with noisy alerts or introducing hard blocks too early.
12
18
13
19
!!! tip "Why this starter set works"
14
-
[OpenSSF](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software.html) recommends prioritizing dependency risk instead of treating all findings as equal, and [OWASP](https://owasp.org/www-community/Component_Analysis) notes that direct dependencies are usually the most practical place to start remediation. CodeScoring research also shows that a useful starter set separates three different risk classes: urgent vulnerabilities that are already exploited and already fixable, critical direct dependencies as the most manageable part of the graph, and very young components that have not yet had enough time to accumulate trust signals from the ecosystem.
20
+
[OpenSSF](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software.html) recommends prioritizing dependency risk instead of treating all findings as equal, and [OWASP](https://owasp.org/www-community/Component_Analysis) notes that direct dependencies are usually the most practical place to start remediation. CodeScoring research also shows that a useful starter set separates three different queues: vulnerabilities that are already exploited and already fixable, direct dependencies with critical vulnerabilities, and very young components that still need additional verification before wider use.
15
21
16
22
## What you will get
17
23
18
-
By the end of this scenario, CodeScoring will contain three active policies:
24
+
By the end of this scenario, CodeScoring will contain three active policies for VCS projects at the `source` stage:
19
25
20
26
- a policy for vulnerabilities with a public exploit and a fixed version at the `source` stage;
21
-
- a policy for critical direct dependencies at the `source` stage;
27
+
- a policy for direct dependencies with critical vulnerabilities at the `source` stage;
22
28
- a policy for very young components at the `source` stage.
23
29
24
30
After a repeated SCA run, you will be able to see which of these rules already produce useful alerts.
@@ -27,7 +33,7 @@ After a repeated SCA run, you will be able to see which of these rules already p
27
33
28
34
Before you start, make sure you have:
29
35
30
-
- access to CodeScoring with permissions to work in `Settings -> Policies`;
36
+
- access to CodeScoring with the `Administrator` or `Security Manager` role;
31
37
- at least one connected VCS project that can be rescanned with SCA;
32
38
- a clear decision on whether this starter set should be applied to all projects immediately or only to a pilot project first.
33
39
@@ -40,7 +46,7 @@ This rule helps surface not just any vulnerabilities, but the ones that are alre
40
46
1. Go to `Settings -> Policies`.
41
47
2. Click **Create**.
42
48
3. Fill in the policy context:
43
-
-**Name** — for example, `Source: exploit + fix`;
49
+
-**Name** — for example, `Exploit and fix`;
44
50
-**Stages** — `source`;
45
51
-**Level** — choose the severity level that fits your process;
46
52
-**Is Active** — enable it;
@@ -51,35 +57,31 @@ This rule helps surface not just any vulnerabilities, but the ones that are alre
51
57
-**Vulnerability has fixed version**.
52
58
6. Click **Create**.
53
59
54
-
```html
55
-
<!-- VIDEO REQUIRED: In CodeScoring, open Settings -> Policies, create a new policy, set its name, choose the source stage, enable Is Active, keep Blocker disabled, add the Vulnerability has exploit and Vulnerability has fixed version conditions, and save the policy. -->
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.
58
62
59
-
After that, the platform will have a rule that raises alerts for the most actionable vulnerability cases in VCS projects.
63
+
After that, the platform will have a rule that creates alerts for the most actionable vulnerability cases in VCS projects.
60
64
61
-
### Step 2. Create a policy for critical direct dependencies
65
+
### Step 2. Create a policy for direct dependencies with critical vulnerabilities
62
66
63
67
Starting with direct dependencies is practical because the list is usually smaller and easier to manage than the full dependency graph. These findings are often easier to assign and fix quickly.
64
68
65
69
1. Open the policy created in the previous step.
66
70
2. Click **Create a copy**.
67
71
3. Change the main fields:
68
-
-**Name** — for example, `Source: direct critical dependency`;
72
+
-**Name** — for example, `Direct dependency with a critical vulnerability`;
69
73
-**Stages** — keep `source`;
70
74
-**Is Active** — keep it enabled;
71
75
-**Blocker** — keep it disabled.
72
-
4. Remove the previous conditions and create a new group with the **AND** expression:
73
-
-**Relation** = `direct`;
76
+
4. Remove the previous conditions and create a top-level group with the **AND** expression:
77
+
-**Relation** = `direct`.
78
+
5. Inside that group, create a nested group with the **OR** expression and add:
79
+
-**CVSS2 Severity** = `critical`;
80
+
-**CVSS3 Severity** = `critical`;
74
81
-**CVSS4 Severity** = `critical`.
75
-
5. Click **Create**.
76
-
77
-
```html
78
-
<!-- VIDEO REQUIRED: On the existing policy page, click Create a copy, change the name, keep the source stage, replace the conditions with Relation = direct and CVSS4 Severity = critical, and save the new policy. -->
At this point, the starter set also includes a separate rule for severe issues in dependencies that the team controls directly.
84
+
At this point, the starter set also includes a separate rule for direct dependencies that have at least one critical severity signal in one of the CVSS versions.
83
85
84
86
### Step 3. Create an informational policy for very young components
85
87
@@ -90,21 +92,20 @@ This rule helps isolate dependencies that were published very recently. For a st
90
92
91
93
1. In `Settings -> Policies`, click **Create** again.
92
94
2. Fill in the policy context:
93
-
-**Name** — for example, `Source: young component`;
95
+
-**Name** — for example, `Component younger than 30 days`;
94
96
-**Stages** — `source`;
95
97
-**Is Active** — enable it;
96
98
-**Blocker** — keep it disabled.
97
99
3. If you want a gradual rollout, specify a pilot project in **Projects** if needed.
98
-
4. In the conditions block, create one group with the **AND** expression and add:
99
-
-**Dependency age (days)** < `30`.
100
+
4. In the conditions block, create a top-level group with the **OR** expression:
101
+
- in the first **AND** group, add **Dependency age (days)** < `30`;
102
+
- in the second **AND** group, optionally add a condition for dependencies where age information is missing.
100
103
5. Click **Create**.
101
104
102
105
If you want to refine the threshold later or extend the rule, the full list of supported criteria is described in [policy setup](/on-premise/how-to/policies.en).
103
106
104
-
```html
105
-
<!-- VIDEO REQUIRED: In CodeScoring, create a new policy, choose the source stage, enable Is Active, keep Blocker disabled, optionally specify a project, add the Dependency age (days) < 30 condition, and save the policy. -->
!!! note "What to keep in mind about dependency age"
108
+
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.
108
109
109
110
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.
110
111
@@ -118,14 +119,9 @@ Policies start working during analysis, so after configuring them it is worth ve
118
119
4. Open the `Policy alerts` section.
119
120
5. Check whether new alerts appear for:
120
121
- vulnerabilities with an exploit and a fix;
121
-
-critical direct dependencies;
122
+
- direct dependencies with critical vulnerabilities;
122
123
- very young components.
123
124
124
-
```html
125
-
<!-- VIDEO REQUIRED: On the project page, start an SCA run, wait until it finishes, then open Policy alerts and show alerts triggered by the new source-stage policies. -->
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.
0 commit comments