Continuous security within DevSecOps

What is continuous security monitoring?

Continuous security monitoring is the natural evolution of security. Modern software development is moving towards a continuous-everything model, from integration to delivery/deployment. Traditional security approaches focus on testing software releases post-production, but this approach creates bottlenecks to development and potentially pushes vulnerabilities into production. Continuous security instead integrates security with the development process, which reduces risk and removes bottlenecks for faster releases.

What are the benefits of using continuous security?

Modern software development is characterized by complex architecture and infrastructure layers, with approaches like cloud native applications, microservices, and containerization allowing developers to test and deliver code faster. Releases are typically small and fast. Environments can see production deployments several times a day.

DevOps security requires a new approach to handle this rapid increase in the rate of change of software. Legacy security methods tested software at the end of the development cycle, or once it went into production. External teams often were responsible for testing, which created friction between developers and security professionals.

On top of this, legacy security approaches are not well-adapted for modern software architectures and infrastructure. Cloud infrastructure can be spun up in minutes. The architecture is not well defined. This is attractive for modern developers, but it creates a broader attack surface that's more difficult to secure. Legacy security approaches are not well-equipped to test these environments.

Continuous security is a natural extension of DevOps practices that integrates security into the CI/CD pipeline. It aligns closely with the DevSecOps concept and the shift left approach to security. Development teams gain ownership and responsibility for code security so issues are detected and fixed as early as possible in the development process. Ultimately, continuous security accelerates the delivery of features, while automating security requirements, leading to better governance and security.

How does continuous security fit into CI/CD pipelines?

Continuous security applies policies and testing directly into the CI/CD pipeline, securing infrastructure and applications at each stage in the software development lifecycle:

Threat modeling

Threat modeling ideally happens at the earliest stages of the SDLC, where developers model changes that would happen as a result of executing code, but without actually executing it. This gives nearly instantaneous feedback. It’s an opportunity to test the security implications of code.

Threat modeling can quickly become complex. One approach, STRIDE, includes a separate analysis for each of the most common types of attacks:

• Spoofing

• Tampering

• Repudiation

• Information disclosure

• Denial of service

• Elevation of privilege

Methodologies like STRIDE help evaluate what you're building, what could go wrong, how you could mitigate that, and how to evaluate your process for threat mitigation.

Threat modeling also requires planning to ensure it fits in well with the DevSecOps culture. Traditionally it consisted of numerous upfront meetings between developers and security experts. Continuous security applies a shift left approach to threat modeling, moving it earlier in the development process, and applying "extend right" to third-party modeling tools to automatically detect and mitigate threats at later stages in the pipeline as well.

Code and design review

Once code is written, it's time to review it to ensure it does what it's designed to do, and to uncover vulnerabilities or security issues. This process should include sanitizing and validating all input using a vetted library, enforcing secured authentication, and scanning for vulnerabilities in software dependencies, and many other security checks.

For more best practices, check out this code review cheat sheet we created.

Testing

Once code has been validated for security and design considerations, it’s time to test it. At this stage, developers build a sandbox capable of going live, then test the code under those conditions. This includes automated testing for network calls, input validation, authorization, logs, and access control. Does the application log security metrics correctly? Is access limited to the correct set of individuals?

Continuous security testing in this manner enables fast feedback. It can include provisioning and testing of infrastructure resources as well. For example, in a test environment deployed on AWS, a tool called Managed Config Rules can be used to ensure that the cloud resource(s) adhere to security configuration best practices.

Production

Production is the end of the line for code, but not for security. Resources can be modified, added, or removed, so applications in production require ongoing testing for compliance with organization, industry, or government standards. Production security can include automated patching, configuration management, and automatic updating of dependencies.

Let’s consider some of the best practices to follow to build an effective continuous security program.

What are the best practices to follow for a continuous security process?

Continuous security requires planning

It’s not as simple as handing security objectives off to the DevOps team and expecting them to apply and enforce procedures. The burden for integrations should not fall to development teams alone. Security teams should focus on applying continuous security with minimal disruption, starting from the planning stage. Security and DevOps should work together to incorporate features and audits from the start, then collaborate throughout the process.

Planning starts with threat modeling at the initial conceptualization of a system, application, or user story. Application security tests should happen automatically at the time of code change and after integration. Any possible concerns should be flagged for review, with results delivered to developers in their native development tools.

The process should be automated as much as possible. Deployment, for instance, should be contingent on security metrics and runtime security.

Infrastructure requires special attention

The flexible nature of cloud infrastructure means policies need to be in place and enforced. This can include disabling services that aren’t needed, closing unnecessary ports, enforcing permissions, and ensuring no development tools are installed in production.

Code must be built on secured operating systems with up-to-date app versions. Security-related controls around cluster size, permissions for shared infrastructure, and infrastructure or platform partners must be enforced as well.

Conduct regular testing (pentests, bug bounty)

Testing is crucial. This ensures code is both functional and secure prior to release. It can also be automated to avoid delays associated with manual verification. Testing can uncover attack vectors, identify potential security vulnerabilities, and categorize them by their potential scope.

This level of testing should also be applied to infrastructure, networks, or anything else that is represented as code. The goal is to analyze all the components of an application to ensure adequate security is implemented for the entire technology stack.

Use tools that foster security without disrupting developers

Modern tools make it simpler for developers to improve security directly within the CI/CD pipeline. Static application security testing (SAST) tools can be used as software is built to find issues and vulnerabilities in code that has been updated. For example, SAST tools can detect if a user input might trigger a database-related function that would introduce a security vulnerability (this is known as a SQL injection security vulnerability).

Traditionally, SAST tools were used as a separate CI process, but modern SAST tools can be used as source code is built to provide fast and actionable feedback to developers. These tools have a low rate of false positives and also give insight into the fix. They’re developer-first, and integrate into the IDE, CLI, and other tools developers already use.

Software composition analysis (SCA) tools are another valuable technology for continuous security. These allow developers to check source code changes for dependency-related vulnerabilities prior to merging.

Policy engines and lint-like tools are two other types of tools that can run whenever a developer delivers code. Secrets management tools like Vault further help to secure code across cloud infrastructure and applications.

Snyk tools for continuous security

There are many tools for finding and fixing vulnerabilities throughout the development lifecycle. Snyk is unique in its developer-first focus and its best-in-class security platform.

For instance, keeping dependencies up to date is a roadblock for developers. How do you know when there’s an update that’s needed? Will changes be useful? Will they introduce bugs or break compilation? Continuous dependency updates, with more frequent and smaller changes, make the problem easier to manage. Developers can use tools to automatically approve and merge updates contingent on passing tests, which ultimately leads to faster deployment times and full automation from pull request to production.

Open-source dependencies are a particular area of concern. Snyk Open Source automatically tests the code through the CI/CD pipeline to uncover and fix vulnerabilities before they go into production. Once code is in production, Snyk monitors for newly uncovered vulnerabilities using a proprietary vulnerability database.

The bottom line is code scans are a key requisite for continuous security. If you don’t have scanning in place, what vulnerabilities or bugs could slip through?