Bandit is a famous SAST utility for testing security issues in Python code. Thisis the second action in the ApplicationValidation stage of our pipeline that executes in parallel to SCA, which we discussed previously.
We also have an error that has been reported here. It seems to point to incorrect usage of exception handling in Python:
- Issue: [B110:try_except_pass] Try, Except, Pass detected.
- Severity: Low Confidence: HighCWE: CWE-703
More Info: https://bandit.readthedocs.io/en/1.7.5/plugins/b110_try_ except_pass.htmlLocation: app.py:35:8
34 return redirect(url_for(‘todos’))
35 except Exception as e:
36 pass
The problem with this code is that we are catching all exceptions and silently ignoring them. This represents a potential security risk as a large number of errors from a service can hint at attempts to interfere with the application. Even if we don’t want to handle the exception in a particular way, we should at least log the failure message and not just suppress it with pass.
Let’s replace the problematic line of code in app.py with a logger statement and commit the changes again:
…return redirect(url_for(‘todos’))except Exception as e:logging.error(“Exception occurred while submitting data to MongoDB”, exc_info=True)…
Now that we’ve fixed this security risk, the last validation check that must be configured in the pipeline involves bringing potential risks, or issues, with the Dockerfile to the surface.
Validating the Dockerfile manifest with hadolint
In addition to linting Docker files, hadolint also performs bash code validations through the shellcheck utility. If you are into writing bash scripts for day-to-day operational procedures, Ihighly recommend using shellcheck, if you don’t use it already.
There are a few errors you will notice in the CodePipeline execution under the PlatformValidation stage that require fixing. Let’s have a look:
……Dockerfile:10 DL3018 warning: Pin versions in apk add. Instead of `apk add <package>` use `apk add <package>=<version>`Dockerfile:22 DL3059 info: Multiple consecutive `RUN` instructions.Consider consolidation.Dockerfile:24 DL3020 error: Use COPY instead of ADD for files and foldersDockerfile:29 DL3042 warning: Avoid use of cache directory with pip. Use `pip install –no-cache-dir <package>`Dockerfile:29 DL3013 warning: Pin versions in pip. Instead of `pip install <package>`use`pipinstall<package>==<version>` or `pip install –requirement <requirements file>`……
While some of these are opportunities to optimize the Dockerfile layer’s structure, the others that ask for specific versions of the libraries to be pinned have some security benefits.
It is always good practice to avoid cached directories for installation and use the latest versions of the libraries. This also goes against the idea of immutability because when new versions of those libraries are released, you might unknowingly end up with a different library version than the one you tested. This can introduce potential security risks if new vulnerabilities were introduced in the latest packages.
To fix the reported errors, we can make the following modifications in the Dockerfile:
# Install packagesRUN apk update && apk add –update –no-cache \bash=5.2.15-r0 \python3=3.10.11-r0 \py3-pip=22.3.1-r1 \py3-cryptography=38.0.3-r1 \vim=9.0.0999-r0 \wget=1.21.4-r0 \curl=8.1.1-r0 \tree=2.0.4-r0RUN apk –no-cache add –virtual \\builds-deps=20230523.220926 \build-base=0.5-r3 && \mkdir /opt/aws-devops-simplified……
With the library versions pinned down and the RUN commands consolidated, we now follow the best practices recommended by the hadolint utility.
Once all these changes have been committed back into the CodeCommit repository, we should have a successful run of CodePipeline, which builds a Docker image and pushes it to the ECR registry that we created as part of the CDK stack.
Summary
In today’s software landscape, security is crucial not only for the financial, social media, and e-commerce sectors but for all industries. With evolving software practices and cloud adoption, the complexity and risks associated with modern applications have increased significantly. These risks, often beyond the control of development teams, can have severe consequences, including reputational damage, information loss, and loss of customer trust. An important concept that helps us address these requirements while ensuring more collaboration among developers, operations, and security team members is DevSecOps.
We started this chapter by introducing what DevSecOps is and the benefits it offers. Similar to DevOps, it is not just about technical optimizations but also promotes the idea of shared responsibility between developers, operations, and security. This ensures that any new risks that the applications might be exposed to are mitigated as soon as possible. After learning about some practical approaches to different test methodologies, we also did a hands-on deployment to experience DevSecOps tools in a CI/CD pipeline. We mostly worked with open source tools as they are already very mature in this space and it’s easy to find the right mix of tools without committing to a broader-scoped service or solution.
In the next chapter, Setting Up Teams for Success, we will cover some ideas that foster collaboration, learning, and growth. We will also focus on the benefits of a no-blame feedback culture.
Further reading
To learn more about the topics that were covered in this chapter, take a look at the following resources:
- Common cloud security issues and threats: https://www.strongdm.com/blog/ cloud-security-issues-risks
- Workshop for threat modeling for builders: https://catalog.workshops.aws/ threatmodel/en-US