🛠 SecScore as an analogue of Quality Gate

Let’s take a look today at a ready-made open-source solution that can be customized out of the box and can simply be reused in your own work (why not? as long as you follow the license 🤔).

SecScore is an open-source tool for assessing build safety using Quality Gate principles. In fact, this is a boxed analogue that everyone should have built in to assess the security and risks of information security, but this tool is tailored to the metrics: weights for criticality, strict conditions and filtering only new defects. I did something similar, but more serious, in the Republic of Belarus, I threw the principle of the concept into the carousel so that you could look at the logic of the work.

Logic

• Score—each vulnerability is assigned a weight, the total score is compared with the threshold. Reached the threshold then the build crashes

• Hard Fails - conditions under which the assembly fails unconditionally, even if the overall score is normal, as an example: any secret in the code, any Critical vulnerability in authorization or other criteria that you set for your project

• Conditions - you can configure the reaction only to new defects, so you will have to file additional exception conditions false [psitive/negative triggers, those should be controlled through an additional mechanism, I try to offer Jira Issue Workflow (previously I described this in a diagram when we touched on the topic with QG here)

Config

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

Example - SecScore creates a comment in PR with the decision made and a list of reasons

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 }}

How does this ultimately work?

• Scored too many points, then a soft threshold for score

• Found something unacceptable, then a hard stop without discussion (business dont like it)

• Simple QGs do not take into account total risk and factors

• Hard Fails capture “red lines” separately from the numerical threshold

• It’s comfortable to start with a soft threshold (threshold: 200) and Hard Fails only for the most critical, well, only the sane and that will really affect the project, but for this you need to manually touch and build a mechanism - also custom

• The threshold is gradually reduced as the debt is closed

• Enable only_new: true during the first implementation, so as not to block the entire pipeline at once

Condition set example

conditions:

- metric: vulnerabilities_critical

operator: GREATER_THAN

value: 0 # none Critical

- metric: vulnerabilities_high

operator: GREATER_THAN

value: 5 # no more than 5 High

- metric: coverage

operator: LESS_THAN

value: 80 # coverage not lower than 80%

- metric: duplicated_lines_density

operator: GREATER_THAN

value: 3 # duplication not higher than 3%

- metric: security_hotspots_reviewed

operator: LESS_THAN

value: 100 # all hotspots checked

Footnote

A Quality Gate is an automatic check that code must pass through before moving forward in the pipeline. Failure - the build crashes, deployment is blocked

#appsec #devsecop #research #toolchain #vulnmanagement #techsolution