Published: Wed 29 November 2023
By Mike Holzinger
In Security .
Why Scan? (A preamble for the middle manager)
Code security scanning involves analyzing source code for potential vulnerabilities and weaknesses that could be exploited by attackers. This process helps identify and remediate security flaws before they can be used to launch attacks, compromising sensitive data and disrupting business operations.
Container security scanning, on the other hand, focuses on detecting and mitigating vulnerabilities within container images, the lightweight and portable units of software that form the basis of cloud-native applications.
Implementing code security and container security scanning into other infrastructure offers several compelling benefits. By automating the process of identifying and addressing vulnerabilities, organizations can significantly reduce their attack surface and enhance their overall security posture. This proactive approach helps prevent data breaches, protect critical assets, and maintain compliance with industry regulations.
Gitlab offers a comprehensive set of container and security scanning tools, provided free to Gitlab users on every tier, and with Gitlab's Ultimate tier, a set of code vulnerability and security reporting dashboards is also included.
Official documentation Static Application Security Testing (SAST)
The scope of this post is to give an example of using the included security scanning tools provided by GitLab first by posting a small Python application with minor code vulnerabilities and then introducing a node.js vulnerability to trigger the Security and Vulnerability dashboards.
] Introduce a web app with weak code security posture
Introduced to the project is Python code that uses Flask to host a rest application that returns the Python version and the container OS version from a REST GET request type.
app = Flask ( __name__ )
@app . route ( '/' )
def index ():
python_version = platform . python_version ()
linux_version = subprocess . check_output ( "cat /etc/os-release" , shell = True ) . decode ()
return f "Python Version: { python_version } \n Linux Version: \n { linux_version } "
if __name__ == "__main__" :
app . run ( host = '0.0.0.0' , debug = True )
] Enabling the Static Application Security Testing (SAST) pipeline template
This commit step enables the built in Gitlab Static Application Security Testing (SAST) template which will run in the gitlab runner pipeline test job.
Involved is including the SAST template, to which the adding the pipeline job, test queues an job in the gitlab runner pipeline execution process.
Items to note:
Enabled and matching pipeline jobs for SAST and GitLab security template(s), require the job step in the GitLab pipeline to be named test: as subsequent templates are defined as children jobs of the test definition.
Defining the Include stanza
Typically, these job templates are prepended and commented out in the first commit to .gitlab-ci.yml and are included by adding a stanza key called "include".
Each template is listed as a string.
stages :
- npm_install
- build
- test
include :
- template : SAST.gitlab-ci.yml
sast :
stage : test
script :
- /analyzer run
artifacts :
reports :
sast : gl-sast-report.json
] Run the SAST test job pipeline step against application code
Running the test pipeline job for SAST is an automatic step which is queued and completed by the gitlab runner.
Output for the pipeline is grouped into the unique pipeline job id.
] Using automatically generated report artifacts
Artifacts (objects) are associated to finished pipeline jobs regardless of the outcome state. The two jobs triggered from the SAST pipeline execution step are listed here.
nodejs-scan-sast
semgrep-sast
This repository has an associated Artifact repository, which GitLab enabled by default for this project.
Artifact naming:
Below is an example artifact name declaration for the sast job step in test.
The gl-sast-report.json artifact is defined to help illustrate naming reports in the artifacts stanza.
This is a default setting that is not neccesary to declare in gitlab-ci.yml as it is defined in the included SAST pipeline template.
sast :
...
artifacts :
reports :
sast : gl-sast-report.json
Further report artifact names are listed below to help complete this explanation.
sast : gl-sast-report.json
container_scanning : gl-container-scanning-report.json
dependency_scanning : gl-dependency-scanning-report.json
cyclonedx : "**/gl-sbom-*.cdx.json"
Note : In all Gitlab user tiers, the report artifacts are generated, and can be downloaded as JSON objects. Artifacts can be fed to a third-party SEIM without using the Gitlab Vulnerability and Security Dashboards.
] Dashboard: Project Security
Gitlab Ultimate tier offers dashboard reporting, which interprets the results the SAST job automatically generated Artifacts.
In this example, the Project Security Dashboard shows that 1 code vulnerability has been flagged as Critical and 3 additional vulnerabilities have been flagged as Medium.
This dashboard is configurable to display vulnerabilities over time with a severity classification.
] Dashboard: Project Vulnerability
Let's drill into the details and find out what this Dashboard tries to tell us.
Drilling into the Vulnerability dashboard, we can see interpreted detail from the gl-sast-report.json
Warnings have been issued for lines 3, 10 and 14 of the app.py server code.
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Description: Consider possible security implications associated with subprocess module.
Severity: Medium
10 linux_version = subprocess . check_output ( "cat /etc/os-release" , shell = True ) . decode ()
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Description: Found subprocess function check_output with shell=True. This is dangerous because this call will spawn the command using a shell process. Doing so propagates current shell settings and
variables, which makes it much easier for a malicious actor to execute commands. Use shell=False
instead.
Severity: Critical
14 app . run ( host = '0.0.0.0' , debug = True )
Active debug code
Description The Flask application is running with debug=True configured. By enabling this option, certain exceptions or errors could cause sensitive information to be leaked in HTTP responses.
Additionally, it is not recommended to run a Flask application using Flask.run(...) in production. Instead, a WSGI server such as gunicorn or waitress be used instead. For more information on deployment options for Flask applications see:
https://flask.palletsprojects.com/en/2.3.x/deploying/
Severity: Medium
] Section summary
As an overview for SAST code inspection, GitLab's Vulnerability dashboard reports the offending line and offers a comprehensive solution to resolve the identified issue.
To end this overview, the vulnerability issues are resolved in the following commit:
] Using the Vulnerability dashboard to confirm and resolve issues
With the critical python issue resolved and committed, a pipeline job has been run and shows the new scan results in the Vulnerability Dashboard.
The Vulnerability Dashboard shows a resolved status and asks for the project operator to "do something" with the posted alert.
Next, by marking the Medium severity vulnerabilities as Confirmed the Dashboard captures the confirmation state for further management.
] Introducing a Node vulnerability to the project
In a commit to add template scanning, a node dependency has been introduced to the project with known security issues.
Further info on lodash: Known vulnerabilities in the lodash package
] Extend GitLab Security Scanning Capabilities with Templates
Extending the GitLab platform's ability to scan, two templates are added to .gitlab-ci.yml deepening the depth of a code security defensive strategy.
Enabled are the following Gitlab security, container and dependancy scanning templates.
include :
- template : Security/Dependency-Scanning.gitlab-ci.yml
- template : Security/Container-Scanning.gitlab-ci.yml
The $CS_IMAGE variable has also been set point to the container intended for scanning.
variables :
CS_IMAGE : "registry.gitlab.com/cipherpop-guidance/containerscanning:main"
Further documentation on setting container scanning variables is hosted at GitLab:
] Validating SAST and newly added test pipeline jobs
Follwing a code commit, the pipeline to scan for vulnerabilities has triggered and a new series of report artifacts have been generated in concert with the newly added templates to scan the defined container and project dependancies.
Completed jobs in the test pipeline job:
] Referencing Vulnerability Dashboard changes
Following the added code vulnerability, the Vulnerability Dashboard is displaying a staggering set of 5 Critical, 59 High, 224 Medium and 503 Low vulnerability issues from the latest pipeline test scanning job.
] Summary
GitLab SAST, Container Security, and Dependency scanning are potent tools available to all tiers.
Additionally, early detection of security flaws can save organizations time and resources that would otherwise be spent on incident response and remediation.
The implementation of code security and container security scanning into code infrastructure is a crucial step towards achieving a comprehensive and effective security strategy. By proactively identifying and addressing vulnerabilities, Code owners and SREs can safeguard data, protect systems, and maintain business continuity.
More info on security can be found at cipherpop.com