Skip to content

feat: add CI tools for creating and evaluating security audit

Luboš Matejčík requested to merge feat/security-audit into main

The MR adds a binary into cli package called catci (😺 + Continuous Integration, pronounced kaci).

catci is a CLI tool intended to be used inside CI/CD jobs and allows us to do more complex operations inside CI/CD jobs which would be rather cumbersome to do in bash scripts.

This MR focuses on use-case: "Let's not allow project's first release into production without security audit document".

Our current release flow:

flowchart LR
    A(Development phase) -->|Finish Development| B(Do first release)
    B -->|Run Create Release CI/CD job| C(Released)

New release flow:

flowchart TD
    A(Development phase) -->|Finish Development| B(Do first release)
    B -->|Run Create Release CI/CD job| C{Does security audit exist?}

    C -->|No audit yet| F(Create Security Audit MR)
    F -->B

    C -->|Audit available| D{Evaluate security audit}
    D -->|Audit is invalid| B
    D -->|Audit is valid| E(Released)
  • Run Create Release CI/CD job: a developer clicks a button (create release) in Gitlab pipeline
  • No audit yet: if SECURITY.md does not exist yet or in other words Security Audit MR is not merged yet
  • Audit is invalid: if SECURITY.md table has zero topics answered - does not have responsible and is answered with placeholder value (/)

To achieve the new release flow, this MR adds following catci commands:

  1. security-audit-create: creates a merge request with empty security audit document and informs developer to fill required information into the document.
  2. security-audit-evaluate: checks if security audit document exists, evaluates security "score" and gives overview of security posture of the project.
  3. security-audit-ci-job: try to evaluate security audit document, if not possible try to create a merge request. Fails with exit codes (0, 1) for pipeline jobs.

Create Release CI/CD job performs security-audit-ci-job command which tries to evaluate security audit and if that fails the release will not be created and instead a merge request with security audit template is created and developer is required to fill in details about security topics of the project in that newly created MR. After a developer merges the merge request created by previous steps the release process will be available.

For now we will only require that the security audit document is present in the repository of the project and has at least one security topic answered. In the future we can think of having a "security score threshold" which would allow releasing of a project based on its security score.

*Security audit document is a simple markdown file in repository's root called SECURITY.md.

Example of filled security audit document (SECURITY.md) is below. security-audit-evaluate command parses information from the table with security topics. Guide links of the document template are available in: https://git.panter.ch/panter/security-guide


Security Audit Report

A security audit report document is a comprehensive assessment of an application's security posture, containing security topics that auditors can mark to indicate the state of various security aspects.

It serves as a structured guide for security team to evaluate different security factors such as authentication, authorization, data encryption, input validation, and more.

General Information

  • Project Owner is @project-owner-gitlab-tag
  • Dev team:
    • @dev1-gitlab-tag
    • @dev2-gitlab-tag
    • @...

Project Security

Responsible / Description Note More information
@dev1 No API keys or secrets are stored in repository guide
@... The app does not provide password login Work in progress
@... Passwords are not stored Work in progress guide
...
Edited by Luboš Matejčík

Merge request reports