fixed more stuff

Author: amaksimovv

docs/tutorials/basic-security-policies.en.md

@@ -11,20 +11,20 @@ After the first analysis in CodeScoring.SCA, you usually get a lot of informatio
 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 direct dependencies with critical vulnerabilities;
+- 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.
 
 !!! tip "Why this starter set works"
-    [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.
+    [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) 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 direct dependencies with critical vulnerabilities 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.
@@ -52,7 +52,7 @@ This rule helps surface not just any vulnerabilities, but the ones that are alre
     - **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 conditions block, create one group with the **AND** expression and add:
+5. In the default top-level conditions group with the **AND** expression, add:
     - **Vulnerability has exploit**;
     - **Vulnerability has fixed version**.
 6. Click **Create**.
@@ -62,26 +62,25 @@ This rule helps surface not just any vulnerabilities, but the ones that are alre
 
 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 direct dependencies with critical vulnerabilities
+### Step 2. Create a policy for dependencies with critical vulnerabilities
 
-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.
+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, `Direct dependency with a critical vulnerability`;
+    - **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 and create a top-level group with the **AND** expression:
-    - **Relation** = `direct`.
-5. Inside that group, create a nested group with the **OR** expression and add:
+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 direct dependencies that have at least one critical severity signal in one of the CVSS versions.
+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
 
@@ -97,9 +96,9 @@ This rule helps isolate dependencies that were published very recently. For a st
     - **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 conditions block, create a top-level group with the **OR** expression:
-    - in the first **AND** group, add **Dependency age (days)** < `30`;
-    - in the second **AND** group, optionally add a condition for dependencies where age information is missing.
+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](/on-premise/how-to/policies.en).

docs/tutorials/basic-security-policies.md

@@ -11,20 +11,20 @@ title: "Настроить базовый набор политик безопа
 Для VCS-проектов на этапе `source` для старта удобно собрать три отдельные политики:
 
 - для уязвимостей с публичным эксплойтом и исправлением;
-- для прямых зависимостей с критичными уязвимостями;
+- для зависимостей с критичными уязвимостями;
 - для слишком молодых компонентов, опубликованных менее месяца назад.
 
 Эти правила помогают быстрее расставить приоритеты, не перегружая команду шумными срабатываниями и не включая блокировки на первом этапе.
 
 !!! tip "Почему именно такой стартовый набор"
-    [OpenSSF](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software.html) рекомендует выстраивать работу с зависимостями вокруг понятной приоритизации риска, а [OWASP](https://owasp.org/www-community/Component_Analysis) отдельно подчёркивает, что прямые зависимости обычно проще всего разбирать и обновлять в первую очередь. Исследования CodeScoring показывают, что на старте полезно не смешивать все сигналы в одно правило, а сразу разделять их по разным очередям: отдельно следить за уязвимостями, которые уже эксплуатируются и уже исправимы; отдельно — за прямыми зависимостями с критичными уязвимостями; отдельно — за слишком молодыми компонентами, которые требуют дополнительной проверки перед широким использованием.
+    [OpenSSF](https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software.html) рекомендует выстраивать работу с зависимостями вокруг понятной приоритизации риска, а [OWASP](https://owasp.org/www-community/Component_Analysis) подчёркивает важность раздельной обработки самых опасных и самых управляемых случаев. Исследования CodeScoring показывают, что на старте полезно не смешивать все сигналы в одно правило, а сразу разделять их по разным очередям: отдельно следить за уязвимостями, которые уже эксплуатируются и уже исправимы; отдельно — за зависимостями с критичными уязвимостями; отдельно — за слишком молодыми компонентами, которые требуют дополнительной проверки перед широким использованием.
 
 ## Что получится
 
 После прохождения сценария в CodeScoring будет три активные политики для VCS-проектов на этапе `source`:
 
 - политика для уязвимостей с публичным эксплойтом и исправлением на этапе `source`;
-- политика для прямых зависимостей с критичными уязвимостями на этапе `source`;
+- политика для зависимостей с критичными уязвимостями на этапе `source`;
 - политика для слишком молодых компонентов на этапе `source`.
 
 После повторного SCA-анализа станет видно, какие из этих правил уже дают полезные срабатывания.
@@ -52,7 +52,7 @@ title: "Настроить базовый набор политик безопа
     - **Активно** — включите;
     - **Блокер** — оставьте выключенным.
 4. Если набор настраивается сначала для пилотного проекта, укажите его в поле **Проекты**. Если нужно распространить правило на все активные проекты, оставьте поля **Подразделения**, **Группы** и **Проекты** пустыми.
-5. В блоке условий создайте одну группу с логическим выражением **И** и добавьте:
+5. В верхней группе условий с логическим выражением **И** добавьте:
     - **Уязвимость имеет эксплойт**;
     - **Уязвимость имеет исправление**.
 6. Нажмите **Создать**.
@@ -62,26 +62,25 @@ title: "Настроить базовый набор политик безопа
 
 После сохранения в системе появится правило, которое будет создавать алерты по наиболее приоритетным и уже исправимым уязвимостям в VCS-проектах.
 
-### Шаг 2. Создайте политику для прямых зависимостей с критичными уязвимостями
+### Шаг 2. Создайте политику для зависимостей с критичными уязвимостями
 
-Начинать с прямых зависимостей удобно, потому что этот список обычно меньше и управляемее, чем весь граф зависимостей. Такие срабатывания проще быстро разобрать и закрепить как рабочий процесс команды.
+Отдельное правило для критичных уязвимостей помогает вынести самые тяжёлые случаи в самостоятельный поток обработки. Для стартового набора это полезно, потому что такие находки легче отдельно контролировать и не смешивать с остальными уровнями риска.
 
 1. Откройте политику, созданную на предыдущем шаге.
 2. Нажмите **Создать копию**.
 3. Измените основные поля:
-    - **Название** — например, `Прямая зависимость с критичной уязвимостью`;
+    - **Название** — например, `Критичная уязвимость в зависимости`;
     - **Этапы** — оставьте `source`;
     - **Активно** — оставьте включенным;
     - **Блокер** — оставьте выключенным.
-4. Удалите прежние условия и создайте верхнюю группу с логическим выражением **И**:
-    - **Связь** = `прямая`.
-5. Внутри этой группы создайте вложенную группу с логическим выражением **ИЛИ** и добавьте:
-    - **Уровень угрозы CVSS2** = `critical`;
-    - **Уровень угрозы CVSS3** = `critical`;
-    - **Уровень угрозы CVSS4** = `critical`.
+4. Удалите прежние условия.
+5. В верхней группе условий выберите логическое выражение **ИЛИ** и добавьте:
+    - **Уровень угрозы CVSS2** = `критический`;
+    - **Уровень угрозы CVSS3** = `критический`;
+    - **Уровень угрозы CVSS4** = `критический`.
 6. Нажмите **Создать**.
 
-Теперь в наборе есть отдельное правило для прямых зависимостей, у которых есть хотя бы одна критичная оценка по одной из версий CVSS.
+Теперь в наборе есть отдельное правило для зависимостей, у которых есть хотя бы одна критичная оценка по одной из версий CVSS.
 
 ### Шаг 3. Создайте информирующую политику для слишком молодых компонентов
 
@@ -97,9 +96,9 @@ title: "Настроить базовый набор политик безопа
     - **Активно** — включите;
     - **Блокер** — оставьте выключенным.
 3. Если набор настраивается постепенно, при необходимости укажите пилотный проект в поле **Проекты**.
-4. В блоке условий создайте верхнюю группу с логическим выражением **ИЛИ**:
-    - в первой группе с логическим выражением **И** добавьте условие **Возраст зависимости (в днях)** < `30`;
-    - во второй группе с логическим выражением **И** при необходимости добавьте условие на отсутствие информации о возрасте зависимости.
+4. В верхней группе условий выберите логическое выражение **ИЛИ** и добавьте:
+    - **Возраст зависимости (в днях)** < `30`;
+    - при необходимости — условие на отсутствие информации о возрасте зависимости.
 5. Нажмите **Создать**.
 
 Если нужно расширить правило или выбрать другой порог риска, список доступных критериев описан в [настройке политик](/on-premise/how-to/policies).
@@ -137,6 +136,6 @@ title: "Настроить базовый набор политик безопа
 
 ## Что дальше
 
-- [разбирают срабатывания в алертах](/on-premise/how-to/policy-results);
-- [настраивают исключения для допустимых случаев](/on-premise/how-to/ignores);
-- [подключают уведомления по политикам](/on-premise/how-to/notifications).
+- [разобрать срабатывания в алертах](/on-premise/how-to/policy-results);
+- [настроить исключения для допустимых случаев](/on-premise/how-to/ignores);
+- [подключить уведомления по политикам](/on-premise/how-to/notifications).

docs/tutorials/block-malicious-components.en.md

@@ -27,6 +27,7 @@ Before you start, make sure you have:
 - access to Docker or Kubernetes together with the OSA Proxy image for the selected installation path;
 - access to the OSA Proxy `application.yml` file and the ability to restart the service after configuration changes;
 - JFrog Artifactory with a remote PyPI repository that can be reconfigured;
+- a CodeScoring license with the **OSA** module enabled;
 - access to CodeScoring with permissions to create policies and review OSA data;
 - a pilot package flow that can be used to validate the setup before rolling it out to all teams.
 
@@ -120,13 +121,13 @@ Now create a rule that works at the `proxy` stage and blocks a component when it
 1. Go to `Settings -> Policies`.
 2. Click **Create**.
 3. Fill in the main fields:
-    - **Name** — for example, `Proxy: dangerous dependency`;
+    - **Name** — for example, `Dangerous dependency at the proxy stage`;
     - **Stages** — `proxy`;
     - **OSA Components** — `Packages`;
     - **Is Active** — enabled;
     - **Blocker** — enabled.
 4. If the rule should apply only to a single delivery channel, choose the corresponding repository. If it should protect all proxy repositories, leave the repository field empty.
-5. In the conditions block create one group with the **AND** expression and add:
+5. Add the condition:
     - **Dependency is dangerous**.
 6. Click **Create**.