DevSecOps Best Practices – Small Changes for a Big Difference

Oliver Moradov

In today’s fast paced agile world, keeping data safe should be everyone’s job, with collaborative and robust security processes in place. To ensure success, especially with multiple iterations of software being pushed into production daily, we need to have a framework in place that will bring the required people, processes and tools together. One such framework is DevSecOps.

Implementing a DevSecOps framework and culture into your business will reduce the need for large-scale security fixes downstream by enabling your teams to make better decisions at the very beginning of their projects.

We will be building on our in-depth article on DevSecOps to focus on six best practices you should follow to implement a DevSecOps framework in your organization, covering

Bonus: What makes Bright the perfect tool for DevSecOps

1. Automate

Speed and automation is crucial for DevOps. The time it takes for code to be pushed to production is imperative and security testing must be part of that workflow, without slowing you down. Developers are releasing 100 times more code than 10 years ago and are introducing security vulnerabilities at the same rate too. Manual tests simply can’t keep up with the speed at which organizations release code today and create too many bottlenecks.

Include automated security controls and innovative security scanning (like Bright’s) early and everywhere in the development lifecycle.

2. Check code dependencies

Despite growing concerns, enterprises are using open-source third-party components more than ever before. With the tight schedule and load of tasks, developers often don’t have the time to analyze all the components they use. We need an automated process for managing those components.

For DevSecOps code dependency checks are fundamental, and tools like OWASP Dependency-Check or Snyk can help you make sure you don’t use components with known vulnerabilities in them.

3. One step at a time

When implementing new tools like SAST to a CI/CD chain, security teams often turn on detection of all supported vulnerabilities, causing frustration and possible conflict with developers. The high rate of false positives with these tools can also impact developer adoption.

Start introducing the tool by setting it up so it detects only a few vulnerability categories, such as SQL Injection. This will give your developers time to get familiar with the tool and understand how it helps them detect vulnerabilities while coding. That will increase adoption of the tool, or reduce the likelihood of it being rejected out of hand.

One step at a time – by disrupting things you will just slow down developers and cause possible conflict.

4. Pick your tools carefully

When choosing the right security tools for your organization, you need to consider these main features:

Integration
One of the key aspects you have to consider is the tools ability to seamlessly and easily integrate into the development pipeline, with a direct feedback loop for developers while also providing the security team and management with full visibility.

Developer First Mindset
With DevOps and CI/CD, security tooling needs to be built with developers in mind – for security scanners, developers need to be able to initiate scans quickly, without leaving their existing toolset, controlling scans via code, or to have global configuration files for security governance.

With most legacy tools being built for security professionals, they can be hard to use, configure and understand the output. Ensuring the tooling truly focuses on enabling developers will maximize success, by leveraging your largest team to spearhead your security efforts

Speed and Accuracy
Without automation and speed, your DevOps and CICD pipelines will either grind to a halt or be ineffective. Speed and accuracy of your security tests and findings respectively is paramount to ensure success. The need to run short, fast. incremental scoped defined tests on every build / commit is important, but the accuracy (or inaccuracy in most cases) can really set you back. Manual validation of security finings is a major bottleneck that compounds security and technical debt and makes it impossible to understand your true cyber posture and to prioritize remediation of fixes. 

Ensuring your tool minimizes the number of false positives (or like in Bright’s case, removes them completely), means you can start to trust the output, create tickets and start to remediate issues immediately. 

5. Threat modeling

Although at number five on our list, this step should be taken, according to SANS Institute, before shifting to DevSecOps. With threat modeling, your security team will not only get a better understanding of the threats, types and sensitivities of your assets, but also what controls for protecting those assets are already in place and/or lacking. A threat modeling exercise will also help your security team to identify any gaps in your controls that need to be addressed.

Threat modeling can help you identify issues in architecture and design that other approaches might have missed. Unfortunately, threat modeling, unlike almost every other facet of DevSecOps, can’t be automated. For that reason it is often considered as a burden for DevSecOps. Organizations are worried that it could slow down the velocity of a CI/CD environment. But that doesn’t mean you should skip or ignore it.

Threat modeling is crucial for your DevSecOps efforts. It helps your developers change their perspective and look at their software as an attacker would do.

6. Secure coding training 

Although historically a challenge was getting the needed management buy-in, investment and time to train development teams on secure coding practices, this is increasingly becoming more popular and rightly so.  

Developers never intend to create insecure software, but organizations prioritize the speed at which new features are released and that they work properly, over being secure. Providing the right training to developers to prevent them from introducing security bugs into their code is a great way of being secure by design, especially when coupled with a dev-first security scanner.

What makes Bright Security the perfect tool for DevSecOps

Traditional (legacy) security scanners are built for security professionals, penetration testers and cyber experts, NOT developers. Bright has been built from the ground up to enhance DevSecOps with a developer first approach, enabling you to shift-left:

  • Bright integrates early into the SDLC: Unlike traditional DAST tools, Bright integrates early into the SDLC allowing you to detect and remediate vulnerabilities early and often
  • Bright tests every aspect of your apps and APIs: Bright is capable of scanning any target, whether web / internal apps, APIs (REST, SOAP, GraphQL, and more), web sockets or mobile
  • Bright seamlessly integrates with the tools and workflows you already use: Bright works with your existing CI/CD pipelines – it triggers scans on every commit, pull request or build with unit tests
  • Developers can spin up, configure and control scans with code: One file. One command. No UI needed
  • NO  false-positive: Bright automatically validates every security finding so you don’t have. Start trusting your output

Start automating your security testing in your pipeline – sign up for a free Bright account and try it yourself.  

Secure your app with every build

Sign up for a FREE Bright account.
Related Articles
Categories