nunet_security_pipeline
Last updated
Last updated
Last updated: 2024-12-22 01:10:50.871108 File source: link on GitLab
Before diving into this please read: DevSecOps Maturity Models
Get yourself familiar with our Vulnerability Management Software: DefectDojo
This document aims to provide a comprehensive overview of the security pipeline architecture implemented in NuNet. It is designed to serve as an informative guide for developers, and stakeholders involved in the software development and deployment process. The primary focus is to detail the various stages of the pipeline, the security tools integrated at each stage, and the specific roles these tools play in enhancing the security of the software development lifecycle. By outlining the workflow, tool specifics, and the conditions under which the pipeline is triggered.
The security tools are applied in different stages of the pipeline workflow. These tools are:
Commit
Secret Detection
Dependency Scanning
Coverage Fuzz Testing (Not in use)
Build
Container Scanning
Test
API Security (Not in use)
Deploy
Operational Container Scanning (TBD)
While GitLab's SAST framework supports many programming languages, at NuNet, our primary programming languages are Python, Golang and JavaScript.
This pipeline applies to both container and binary projects.
This pipeline is triggered on merge request to every branch.
It is run on the test (or Security-Test-1) stage.
The Secret Detection tool scans repositories to help prevent secrets from being exposed during commits. The primary Secret Detection tool is Gitleaks.
This pipeline applies to both container and binary projects.
Gitleaks is used for secret detection in repositories.
This pipeline is triggered on merge request to every branch.
It is run on the test (or Security-Test-1) stage.
This stage analyzes an application's dependencies for known vulnerabilities.
The primary tool for scanning application dependencies is Gemnasium.
This pipeline is currently disabled but can be configured to run every branch commit.
It is run on the test (or Security-Test-1) stage.
The container scanning tool inspects docker images for known vulnerabilities.
After building the docker image, the following tools scan the built containers.
Trivy (Default Gitlab container scanner)
This pipeline is triggered on merge request to every branch.
This stage is run on the test (or Security-Test-1) stage, primarily after the build stage.
Static Depth
Run SAST scans with minor tweaks to rules. ✅
Run SCA scans with minor tweaks to rules. ✅
Run Secret scans with minor tweaks to rules. ✅
Dynamic Depth
Run DAST scans with minor tweaks to baseline settings. (Binary case) ❌
Run DAST scans with minor tweaks to baseline settings. (Container Scanning) ✅
Intensity
Scans to be twice a month. Frequency here is too much, every commit on every branch
Consolidation
The findings in a vulnerability register after analysis. Vulnerability Management Process designed for this purpose