Guido Vrola - Fotolia
Automate security testing and scans for DevSecOps success
Attackers are knocking at your door. Don't waste time with repetitive, automatable security tasks. Here's how DevSecOps enables code analysis, security testing and more.
When security teams automate testing and tasks, they can do more in less time. Information security engineers, for example, can use automation to protect and harden each release of software code. In fact, CI/CD pipelines are a security engineer's dream.
DevSecOps pipelines combine application code creation, security checks and deployment and support operations into an automated sequence of steps, linking together multiple tools. Security engineers can automate away many boring tasks, simultaneously empowering DevOps teams and boosting security posture. When infosec engineers have more time on their hands, they can work on more labor-intensive security issues that continuously threaten the business.
DevSecOps can be a win-win for security and developers alike. When teams follow DevSecOps best practices, they can write resilient code and test against real-world attack scenarios. In this article, we'll cover best practices and tools to automate security with DevSecOps pipelines.
Assess the resources
Automated security vulnerability tests in a DevSecOps pipeline ensure that some process checks the resources for known weaknesses.
API-enabled services, such as Azure Advisor and the AWS Well-Architected Framework, can analyze and report on whether cloud instances are configured optimally. These services show ways to increase performance, reduce cost and quickly take action to follow best practices with cloud infrastructure.
Where APIs are available to interact with these cloud resources, it's easy to add a step in the DevOps pipeline that determines the security of deployed code. The architect should decide if he wants that step to simply audit the environment and report back, or take action to make measurable improvements, such as implement data access restrictions.
Analyze code
Security automation can provide some insurance in code analysis. Every pipeline has a build step for software code, at which a tool gathers all the artifacts that will deploy. Immediately after this step, the code should get scanned to identify any problem areas -- and it's a better task for a tool than for a mistake-prone human.
Code analysis tools like Veracode, Codacy and Micro Focus Fortify integrate with the DevSecOps pipeline to scan code. They can move a release along with an all-clear, or alert developers to pause a deployment due to a critical vulnerability -- thus preventing insecure code in production.
When incorporating code analysis into pipelines, make sure to enhance the team's DevOps capability, not hinder its release cadence. Nothing makes a developer ignore security responsibilities faster than a report full of false positives. Carefully tune code analysis scans to catch true vulnerabilities and keep false positives off developers' already busy to-do list.
Scan all environments
Not all bugs manifest in all environments. In fact, some defects behave differently from one space to the next, such as from development to production. To prevent code problems from becoming user-facing issues, implement scans as early as possible. Scan all environments: development, quality assurance, staging and production.
The earlier you catch insecure code, the more likely that you can fix it before the vulnerable code reaches the production environment or causes a release delay. Catching bugs early eliminates risk, maintains the release cadence and enhances the security posture of the business.
Automate security testing and configuration management
Automated security testing analyzes environments to make sure they meet expectations. Organizations mandate particular environment configurations to meet security and performance goals, but you don't know that the configuration is as expected without testing.
Processes like white box and black box testing can help QA engineers pinpoint potential vulnerabilities before it's too late. If configuration is out of specification, the software team can halt the release and remediate the security deficiencies themselves, or alert the security team. Remediation on the fly might be the better option if automation is in place, such as declarative configuration management, to handle configuration drift.
If you have both red teams -- aggressive fake attackers -- and blue teams -- their counterparts enacting defenses -- in security, this is also the phase in which you should launch real attacks against your code. If the app can't handle it, it's time to go back to the drawing board with the developers to make the product more resilient. If the app passes, push to production with peace of mind.
