A major issue in modern software development is the fact that most organizations are quick to adopt containers and automation, but remain behind the curve in adopting DevSecOps processes that ensure container security. By sharing the responsibility of security across all software teams, organizations can begin to identify vulnerabilities earlier in their SDLC (software development lifecycle) and engrain security and compliance into their current and future CI/CD (Continuous Integration/Continuous Delivery) workflows.
Empowering Developers Before CI/CD
One of the first steps an organization should take towards sharing the responsibility of security across all teams is to empower their developers with visibility and knowledge into security threats. As the ones who initially create and improve code, developers need to be aware of the weaknesses in the packages and libraries they are using. Since developers are typically working on local machines, Anchore has created open source CLI tools that enable developers to generate SBOMs (software bill of materials) and identify vulnerabilities not only in container images but also in code and filesystems. Currently in pre-release, Syft and Grype are ideal for projects in development and will soon include automated vulnerability scanning with IDE (integrated development environment) plugins. This allows for development and security teams to communicate and remediate security threats prior to wasting time or money on operational resources.
Automating Security During CI
Once the development and security teams have acknowledged and accepted the threat level in a software project or feature, they may decide to run the code through a CI pipeline. These pipelines are usually owned by DevOps (development operations) Engineers and may include stages like building a container image, running tests, and pushing the image to a registry.
In order to share the responsibility of security across teams, an organization should ensure there is a vulnerability scanning and compliance stage in every pipeline. With easy integration with CI tools such as GitLab CI, Jenkins, and AWS CodeBuild, Anchore Enterprise 2.4.0 makes it simple for operations teams to incorporate things like malware scanning, base image comparisons, and enhanced vulnerability feeds to discover vulnerable points in the attack surface that the development team would have missed. When Anchore finds vulnerable points in the attack surface, future pipeline stages can be configured to fail and the operations team can be alerted so that development and security teams can work to resolve the security issue.
Ensuring Compliance During CD
When a feature is ready and it comes time to deploy into production through an orchestration tool such as Kubernetes, it is important that organizations remain vigilant in their “final evaluation” of a container image before runtime. The security team may have requirements like blocking containers from using specific packages, ports, or user permissions. The organization may have a mandated level of compliance to achieve such as DISA, NIST, or PCI DSS compliance. Anchore makes it simple for the security team to enforce security and compliance checks with policy as code.
Additionally, the Anchore Admission Controller can ensure non-compliant containers are blocked from being deployed. Regardless of whether someone is attempting to deploy containers with a CD tool like Argo or by creating a pod, deployment, or stateful set, the Anchore Admission Controller will evaluate each container against the security team’s policy before deciding to deploy or not deploy.
Conclusion
As attackers are constantly looking to take advantage of vulnerable points, organizations should be looking for their own vulnerable points. By sharing the responsibility of security across all software teams, modern organizations can begin identifying threats earlier and automating container security processes in their CI/CD workflows.
