DevSecOps combines software development (Dev), security and information technology operations to reduce the development cycle and secure the outcome. The DevSecOps Mission aims to create a Continuous Monitoring (CM), which is available for all Department of Defense mission partners. This monitors and enforces compliance for containerized applications. It covers all DevSecOps Pillars (Develop Build, Test Release & Deploy), and focuses on automation and integration in the future. Here’s how it works.
>”>
What is DEVSECOPS?
DevSecOps combines software development (Dev), security and operations (Ops), to reduce the development cycle and deliver a secure product. DevOps is a combination of security practices at both the Dev- and Ops phases. It is not an independent phase. Developers can now deliver software updates, patches, and fixes faster to users by implementing a DevSecOps procedure. This process is automated and repeatable.
Development categories in devsecops
The development phase is where the application’s development is completed. This phase can be divided into five categories: Building, Testing and Publishing. These categories can be called something else or merged to create one category. However, the general tasks of this phase will remain the same. Any category can lead to a return of a previous category during development.
Coding refers to the process used to develop applications and infrastructure codes, as well as code design and security review. Testing involves the use testing tools to perform continuous testing to provide quick feedback on business risks. Securing is the use security tools to continuously scan images for vulnerabilities and security findings.
The contributor and the Iron Bank Container Hardener are responsible for the coding and testing tasks within the Iron Bank flow. The contributor is responsible to develop the container and run tests against it to verify that it meets the organization’s test criteria. After the contributor has completed the testing and coding, the Iron Bank Container Hardener will work with the contributor to ensure that the container is safe before it is introduced to the Iron Bank Pipeline. The standards for artifacts and their allowed contents are established to allow the Iron Bank pipeline to receive the pull request (PR). The Iron Bank pipeline will require that contributors comply with the security requirements.
Building
It is important to control the inclusion and deletion of dependencies during the Iron Bank pipeline’s build stage. Iron Bank can control dependencies by using trusted sources and the type of commands that are included in the build files. Although the dependencies are from trusted sources, Clam AntiVirus (AV), runs them to ensure they are free of malware and viruses. Once the dependencies have been verified to be secure, they can be moved to the artifact repositories. There is no need for them to be moved outside of the Iron Bank infrastructure to build the container image. The new image is uploaded to the artifact repository after the build is complete. UNCLASSIFIED Container Image, Deployment Guide V2 R0.6 DISA 02/11 2020 Developed
The Iron Bank pipeline is designed to build hardened containers. It does not care about the type of build (java, Python) being used, so many of its steps reflect its general purpose.
Secure
After the successful construction of the container image within the pipeline, security vulnerabilities are checked. To determine if there are any vulnerabilities in the container image, security tools such as Anchore, Prisma, and OpenScap scan it. You should use more than one scanner to get the best results. These tools produce reports that show the vulnerability, the fix and the severity. These reports can be used by the Iron Bank Common Vulnerabilities (CVE) Approver to determine which vulnerabilities must be fixed before publication. Following Section 2 security requirements will reduce the vulnerability found by security tools, allowing for a container picture to require a smaller list of findings.
Publishing
Any vulnerabilities discovered during security scans must be fixed before the container image is released to the public. The contributor and the Iron Bank CVE Advover review the findings throughout this phase. Each vulnerability is either signed by the Iron Bank CVE APProver, creating an official whitelist of findings, OR it is solved by the contributor. If the contributor doesn’t understand the vulnerability, the Iron Bank CVE Approver can work with them to help them understand it and fix it if necessary. If the vulnerability in the container image is too severe to be released by the contributor, they must make the required fixes and create a new container image.
