🛠 SecScore как аналог Quality Gate

Давай сегодня посмотрим с тобой на готовое open-sourse решение, которое из коробки кастомится и просто можно переиспользовать в своих работах (почему бы и не да? если только соблюдать лицензию 🤔).

SecScore — open-source для оценки безопасности сборки путем использования принципов Quality Gate. По сути это коробочный аналог, который должен быть у всех встроен для оценки безопасности и рисков ИБ, но эта тула заточена под метрики: веса по критичности, жёсткие условия и фильтрация только новых дефектов. Я что то подобное, но более серьозное делал в РБ еще, принцип концепта я в карусель закинул, что бы ты мог посмотреть на логику работы.

Логика

• Score — каждой уязвимости присваивается вес, суммарный score сравнивается с порогом. Достигли порога тогда сборка падает

• Hard Fails — условия, при которых сборка падает безоговорочно, даже если общий score в норме, как пример:любой секрет в коде, любая Critical-уязвимость в авторизации или иные критерии которые поставишь ты для своего проекта

• Условия — можно настроить реакцию только на новые дефекты, поэтому тебе придется пилить напильником дополнительно условия исключений false [psitive/ negative сработок, тех долг контролировать через дополнительный механизм, у себя я стараюсь предлагать Jira Issue Workflow (ранее описывал это на схемке, когда трогали тему с QG тут)

Конфиг

score:

threshold: 100

weights:

critical: 50

high: 20

medium: 7

low: 1

hard_fails:

- severity: critical

rule: "sql-injection"

- severity: high

rule: "hardcoded-secret"

- type: secret

severity: any

- rule_id: "CWE-78"

severity: critical

conditions:

only_new: true

Пример - SecScore создаёт комментарий в PR с принятым решением и перечнем причин

name: Security Gate

on:

pull_request:

branches: [main]

jobs:

secscore:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- name: Run SAST (Semgrep → SARIF)

run: |

semgrep ci --sarif --output results.sarif

- name: Run SecScore

run: |

secscore \

--sarif results.sarif \

--config secscore.yaml \

--pr-comment \

--github-token ${{ secrets.GITHUB_TOKEN }}

Как в итоге это работает?

• Набрали слишком много баллов, тогда мягкий порог по score

• Нашли что-то недопустимое, тогда жёсткий стоп без обсуждений (бизнес dont like it)

• Простые QG не учитывают совокупный риск и факторы

• Hard Fails фиксируют «красные линии» отдельно от числового порога

• Комфортно начинать с мягкого порога (threshold: 200) и Hard Fails только на самое критичное, ну только вменяемое и что реально аффектит проект, но для этого тебе надо ручками потриажить и построить механизм - тоже custom

• Постепенно снижается порог по мере закрытия долга

• Включить only_new: true при первом внедрении, чтобы не заблокировать весь пайплайн сразу

Пример набора условий

conditions:

- metric: vulnerabilities_critical

operator: GREATER_THAN

value: 0 # ни одного Critical

- metric: vulnerabilities_high

operator: GREATER_THAN

value: 5 # не больше 5 High

- metric: coverage

operator: LESS_THAN

value: 80 # покрытие не ниже 80%

- metric: duplicated_lines_density

operator: GREATER_THAN

value: 3 # дублирование не выше 3%

- metric: security_hotspots_reviewed

operator: LESS_THAN

value: 100 # все hotspots проверены

Сноска

Quality Gate — это автоматическая проверка, через которую должен пройти код, прежде чем двинуться дальше по пайплайну. Не прошёл — сборка падает, деплой блокируется

#appsec #devsecop #reserch #toolchain #vulnmanagement #techsolution