Getting Started in DevSecOps

Getting Started in DevSecOps Informed

What is DevSecOps? Simply, DevSecOps is DevOps. DevOps always included security, but adding those 3 letters adds emphasis on the security part of the mission. What we want to accomplish with DevSecOps is a scalable security program embedded at every step of the software development lifecycle.

Principles of DevSecOps

DevSecOps has a number of core principles:

  • Culture: DevSecOps is all about a culture of collaboration. Being in a separate part of the company or reporting to a different manager doesn’t mean you aren’t on the team. You have the same mission! Security is built by Developers, SREs, and the sales team. 
  • Automation: To consistently scale security, you need automation. Eliminate tedious tasks and manual labor. Automate everything and it becomes a natural part of the process.
  • Transparency: Internally, open source your security program. Involve developers and stakeholders, giving them agency in the security program. You cannot build security in a bubble.
  • Empathy: The truth is, security can be frustrating. It sometimes interrupts the natural development process of the team. Be available, be open, and welcome feedback.

Benefits of DevSecOps

  • Develop Faster – Legacy security programs are plagued by “security block” work because the security team was only looped in at the end of the development process. DevSecOps allows us to identify risks early and along the way.
  • Lower Cost – It is cheaper to resolve a vulnerability before it’s in production.
  • Better Security Posture – When security is automated at every step of the process, fewer risks get past the development stage. Additionally, with DevSecOps, security becomes a shared responsibility among stakeholders.
  • Scalability – Automated security testing scales with the pace and size of your business. This allows you to build securely, at the pace of relevance, and remain consistent.

What to avoid when starting DevSecOps

In the first phase of your program you can rack up some quick wins but you must avoid an important pitfall. That pitfall is blocking builds. During phase one of your program, tune your automated security testing so you don’t completely stop all active work overnight by testing in the pipeline. This builds confidence in your program and gets your developers in the habit of including security in their process. 

Don’t turn on automated scans in a blocking state from day one or work on existing projects grinds to a halt. Developers get overwhelmed by vulnerabilities (most are false positives) and won’t want to work with you. If you lose the trust of your app teams, regaining it delays your program. Additionally, every test adds time to the software development process. Especially when starting out, make sure your tests are quick and efficient. A general caveat is that your security tests should run in less than 5 minutes. These tests can run in parallel, often with other build steps to save time. Remember, time is money.

Getting Started

Static security testing is a quick and easy way to get started without adding significant complexity or time to your software development process. Here are some core security tests to add to your pipeline in the early stages of your DevSecOps program:

  • SCA/OAST: Open-source application security testing checks your third party libraries/frameworks used in your code for vulnerabilities. Up to 80% of code is actually someone else’s through the use of third party and open source libraries. Many of the major data loss events in the past decade have been through vulnerabilities in the software supply chain. Keeping third party libraries up to date is critical to secure software development. Common SCA/OAST tools are:
    • Snyk – Multi-language and does more than just SCA/OAST
    • RetireJS – A free and open source Javascript scanning tool.
    • Bundler-audit – A free and open source tool for scanning Ruby Gems.
  • SAST: Static application security testing scans your code for grepable patterns that cause common vulnerabilities. You can test for common patterns such as not validating external input in your web components. Common SAST tools are:
    • Snyk – Multi-language and does more than just SAST
    • Bandit – A free and open source vulnerability scanner for python
    • Brakeman – A free and open source vulnerability scanner specifically designed for Ruby on Rails applications.

Secrets Scanning

A common shortcut in software development is to hard code secrets directly into your code. That code gets committed in plain text to your version control system such as Github. Anyone with access to that code has access to your secrets. If a single developer gets compromised or a repo is accidentally committed publicly, all of those secrets are public, in moments. Bots constantly scan public repositories for secrets to use in malicious attacks. Secrets scanning can prevent secrets from being committed at all through pre-commit hooks and alert the team for any secrets already committed. Even if a Pull request is not merged, that secret is in the git history. Common Secrets-Scanning tools are:

  • Trufflehog – Trufflehog is a free and open source tool that scans your local filesystem and codebase and your entire version control system including the Git history.
  • Gitleaks – A free and open source scanner for git repositories, files, and directories.
  • GitGuardian – A commercial tool that scans your Git repositories’ history and monitors new contributions in real time for secrets.

What is Next?

There is no one size fits all guide to everything your organization needs. You must understand your software building process and risk exposure. Here are some additional projects you can undertake to continue automating security in your software development lifecycle:

  • DAST – Dynamic Application Security Testing scans web application components for common vulnerabilities. Unlike SAST which runs directly on your code, DAST runs against the built version of your application and has no understanding of the underlying code. Common DAST tools are:
    • OWASP ZAP – A full featured open source DAST tool that includes automated scanning and manual web application penetration testing.
    • StackHawk – A commercially supported DAST tool built on OWASP ZAP and optimized to run in your CI/CD pipeline.
  • IAC Scanning – As organizations make their DevOps transformation they codify their infrastructure using languages such as AWS CDK, Pulumi, and Terraform. IAC scanning allows you to detect misconfigurations in your infrastructure as code stack and prevent them prior to becoming a risk. Common IAC scanning tools are:
    • Snyk – Offers multi-language support and also includes other security testing features like SAST and OAST.
    • Checkov – A free and open source scanner that supports multiple platforms.
  • Container Scanning – If you are leveraging containers in your DevOps program, you need to scan your Dockerfiles and container images for vulnerabilities. This includes using Amazon ECS, Kuberenetes, dockerswarm, and more. Common tools for scanning your container files and images are:
    • Snyk – Scans Dockerfiles and images for vulnerabilities. Supports other testing such as SAST, SCA/OAST, and IAC scanning.
    • Trivy – An open source comprehensive scanner that supports multiple targets.

Conclusion

The world of DevSecOps is grand, with endless possibilities! This isn’t a comprehensive list of all DevSecOps practices, but a good starting point. In future blog posts we will share more in-depth looks at how to accomplish a number of these steps and explore more of the DevSecOps world.

author avatar
Trevor Costanzi Security Engineering Lead
Trevor Costanzi is Security Engineering Lead at Informed.IQ. He has over a decade of technology experience and specializes in building scalable security into the Product Engineering lifecycle in a way that improves organizational security and product velocity.

Just Released: Auto Loan Defect Industry Survey Report

X