In one of my posts, I described how you can literally connect SAST scanners to the pipelines of your repositories in just a couple of lines.
This is very convenient, because you don’t even need to know what kind of scanner you will be using, because GitLab will automatically select the appropriate scanner, depending on what programming language you are using.
However, launching a security scanner is only the beginning of the journey. It is necessary to somehow work with the scan results.
GitLab has a small dashboard, but unfortunately, only in the Ultimate version, which is not available for free.
Well, there are 2 options left, either we look at the reports with our eyes (ha-ha), or we can use a third-party solution that can parse scan results and display them.
semgrep vs GitLab SAST
Let’s first compare what the result of scans from the original semgrep and semgrep, which is launched by GitLab, looks like.
Original semgrep scan results
{
"check_id": "python.lang.security.insecure-hash-algorithms.insecure-hash-algorithm-md5",
"end": {
"col": 37,
"line": 35,
"offset": 1022
},
"extra": {
"fingerprint": "ba2894c0519693c9c48c6c47e8369de2f194acfb1d91641cf5fc386998a4904f2d88cfd2883178e949931b663358fc1fae31974d4647eb5ec52bf6d10bb578ae_0",
"fix_regex": {
"regex": "md5",
"replacement": "sha256"
},
"is_ignored": false,
"lines": " checksum = hashlib.md5(src_file).hexdigest()",
"message": "Detected MD5 hash algorithm which is considered insecure. MD5 is not collision resistant and is therefore not suitable as a cryptographic signature. Use SHA256 or SHA3 instead.",
"metadata": {
"asvs": {
"control_id": "6.2.2 Insecure Custom Algorithm",
"control_url": "https://github.com/OWASP/ASVS/blob/master/4.0/en/0x14-V6-Cryptography.md#v62-algorithms",
"section": "V6 Stored Cryptography Verification Requirements",
"version": "4"
},
"bandit-code": "B303",
"category": "security",
"cwe": "CWE-327: Use of a Broken or Risky Cryptographic Algorithm",
"license": "Commons Clause License Condition v1.0[LGPL-2.1-only]",
"owasp": "A3: Sensitive Data Exposure",
"references": [
"https://tools.ietf.org/html/rfc6151",
"https://crypto.stackexchange.com/questions/44151/how-does-the-flame-malware-take-advantage-of-md5-collision",
"https://pycryptodome.readthedocs.io/en/latest/src/hash/sha3_256.html"
],
"shortlink": "https://sg.run/9odY",
"source": "https://semgrep.dev/r/python.lang.security.insecure-hash-algorithms.insecure-hash-algorithm-md5",
"source-rule-url": "https://github.com/PyCQA/bandit/blob/d5f8fa0d89d7b11442fc6ec80ca42953974354c8/bandit/blacklists/calls.py#L59",
"technology": [
"python"
]
},
"metavars": {},
"severity": "WARNING"
},
"path": "unit_test/files/test_management.py",
"start": {
"col": 16,
"line": 35,
"offset": 1001
}
}Results of a semgrep scan run by GitLab
{
"id": "afe266c376f1decbbaad8a3eca4a4f23afe2c87ee212552577e8ddef58fa031b",
"category": "sast",
"name": "Improper restriction of XML external entity reference",
"description": "The application was found using the `lxml.etree` package for processing XML.\nPython's default XML processors suffer from various XML parsing vulnerabilities\nand care must be taken when handling XML data. Additionally, depending on the\nversion of Python, more critical vulnerabilities such as eXternal XML Entity\ninjection maybe exploitable.\n\nThe `etree` package suffers from the following security risks as of Python 3.7.1:\n* Billion laughs / exponential entity expansion - May allow an adversary to cause\n a Denial of Service (DoS) against the application parsing arbitrary XML.\n* Quadratic blowup entity expansion - Similar to above, but requires a larger input\n to cause the Denial of Service.\n\nTo remediate the above issues, consider using the\n[defusedxml](https://pypi.org/project/defusedxml/)\nlibrary when processing untrusted XML.\n\nExample parsing an XML document using defusedxml:\n```\nfrom defusedxml.ElementTree import parse\n\n# Parse the inventory.xml file\net = parse('inventory.xml')\n# Get the root element\nroot = et.getroot()\n# Work with the root element\n# ...\n```\n\nFor more information on the various XML parsers and their vulnerabilities please see:\n- https://docs.python.org/3/library/xml.html#xml-vulnerabilities\n\nFor more information on XML security see OWASP's guide:\n- https://cheatsheetseries.owasp.org/cheatsheets/XML_External_Entity_Prevention_Cheat_Sheet.html#python\n",
"cve": "semgrep_id:bandit.B320:811:811",
"severity": "Medium",
"scanner":
{
"id": "semgrep",
"name": "Semgrep"
},
"location":
{
"file": "swagger_server/parsing/parsers/base.py",
"start_line": 811
},
"identifiers":
[
{
"type": "semgrep_id",
"name": "bandit.B320",
"value": "bandit.B320",
"url": "https://semgrep.dev/r/gitlab.bandit.B320"
},
{
"type": "cwe",
"name": "CWE-611",
"value": "611",
"url": "https://cwe.mitre.org/data/definitions/611.html"
},
{
"type": "owasp",
"name": "A03:2021 - Injection",
"value": "A03:2021"
},
{
"type": "owasp",
"name": "A4:2017 - XML External Entities (XXE)",
"value": "A4:2017"
},
{
"type": "bandit_test_id",
"name": "Bandit Test ID B320",
"value": "B320"
}
]
}Of the biggest shortcomings that immediately catch your eye:
- In the GitLab version, the scanner report does not have a section with the code section in which the defect was found
- The version from GitLab does not have information about automatic fixing, which is presented in the original report in the fix_regex section
One of the advantages that can be noted is that in the GitLab version, Markdown is used in the description of the defect, which makes it more convenient to work with the issue.
How to conveniently work with SAST results
As I already said, GitLab does not provide a tool in its free version for working with scan results. Well, let's take a look at possible alternatives:
- free ASOC from Hexway
Of course, there are many more tools for working with scan results. I will tell you more about ASOC and ASPM class tools in the next post.
Join me on LinkedIn and stay updated on the latest DevSecOps industry trends, valuable insights, and exciting opportunities!
