Every stage of the pipeline validates some or the other aspect of the application against security risks. We follow the same inside-out principle and start from the application itself, before moving on to Docker validations.
Software Composition Analysis with dependency-check
If you observe the output of the pipeline execution, you will notice that the first stage, ApplicationValidation, reports an error in the SCACheck CodeBuild action. Checkingthe CodeBuild build execution log reveals a finding in the Flask framework and since the criticality exceeds the threshold value of 7 (as configured in the buildspec.yml file), an error has been raised. Such security validations flag any new dependency that your developers might introduce into the application. The criticality of these findings can vary, and not all would be relevant, but having some false positives is still better than no reporting at all.
In this case, the OWASP dependency-check utility, in addition to flagging a potential risk, gives us a URL that contains more information about the specific CVE that has been reported:
“vulnerabilities”: [{“source”: “OSSINDEX”,”name”: “CVE-2023-30861″,”severity”: “HIGH”,”cvssv2″: {“score”: 7.5,……”cwes”: [“CWE-539″],…”description”: “Flask is a lightweight WSGI web application framework. When all of the following conditions are met, a response containing data intended for one client may be cached … https://ossindex.sonatype.org/vulnerability/CVE-2023-30861…
As shown in Figure 9.4, visiting the CVE URL in your web browser further explains how certain configurations in the Python Flask framework can be exploited. dependency-check parsed the requirements.txt file to figure out the third-party dependency names and their version. It then verified these dependencies against the publicly available vulnerabilities database – in this case, NVD. Since the version we are using in the application is flagged as a potential risk, it was called out by the dependency-check utility. However, in this case, we are not working with cookies or headers,so we can safely suppress the finding:
Figure 9.4 – CVE finding reported by the dependency-check utility
Tip On every run, utilities such as dependency- check download all the CVEs from public databases and store them locally for evaluation. As CodeBuild environments are ephemeral, it leads to a loss of information every time the build completes. This results in really high execution times (>5 minutes) for each run. This can be optimized by leveraging CodeBuild build caches that allow you to mark a directory that needs to be saved and reused in subsequent build runs. You can read more about this feature athttps://docs.aws.amazon.com/ codebuild/latest/userguide/build-caching.html.
For simplicity’s sake, let’s say we are not interested in any vulnerability findings where the CVSS score is below 8. We can adapt the respective buildspec file for the CodeBuild action and commit the changes. To do this, we can modify the CVSS threshold to 8 in the buildspecs/sca.yml file:
…build:on-failure: ABORTcommands:- dependency-check –scan “${PWD}” –enableExperimental–failOnCVSS 8 –format JSON……
By default, this utility dumps a report file after the command’s execution is complete. In addition to JSON, there is support for several other formats, which can be automatically parsed for any additional automation you want to build on top of it. After making these changes, you can push the new updates to the repository hosted on AWS:
aws-devops-simplified:~/environment/chapter-9/chapter-9-flask-app $ git commit -am “Increased threshold for CVSS score in SCA check”[master 73db6e9] Increased threshold for CVSS score in SCA check 1 file changed, 1 insertion(+), 1 deletion(-)aws-devops-simplified:~/environment/chapter-9/chapter-9-flask-app $ git push origin masterEnumerating objects: 7, done…….0032123..73db6e9 master -> master
Next, we can move on to the outputs of the SAST stage.