Building the partnership with DevOps is crucial for the start of your DevSecOps journey

Mar 2, 2020

Your first steps in DevSecOps ideally are frictionless and valuable at the same time for your stakeholders.  From our DevSecOps consulting practice five key measures should be executed, focused on building the partnership with DevOps. These are crucial steps for the start of your DevSecOps journey.

Train all engineers on Secure Coding, without expecting all of them becoming security experts 

Every person on the DevOps team should have security training, the intensity should vary with the role in that team. Engineers must be trained in the basics of secure coding, and learn to get to know the mindset of a hacker.

For example, most application layer vulnerabilities could be addressed by whitelisting input and filtering out extraneous characters. The root cause of SQL injection and cross-site scripting is the lack of input sanitization. The same principle applies to input from data and configuration files and network traffic.

Do not change job profiles to make your Developers security experts, as that might create friction in workload and career interest. Some will emerge as new security champions, which will benefit the more complicated steps later on in the journey.

 

Do not try to adapt engineers to your security tools and processes

Offer first steps of integrated and continuous security assurance that appear seamless for engineers throughout the continuous integration/continuous deployment (CI/CD) toolchain and processes.

This means

  • Never make engineers leave their native toolchain environment. This means integrating testing — ideally on a near-real-time basis — with IDE and CI/CD toolchain tools.
  • Architecting your security and compliance scanning to be performed via APIs rather than through the native console of the security vendor.

This also means that you should…

Prepare for extensive tuning to use DAST and SAST solutions  

Take these steps :

  • Start experimenting with simple testing integrated directly into the IDE. Although these scans can’t find everything, in the spirit of DevSecOps, they provide useful feedback on coding issues early in the development process, without waiting on a build to be performed in the CI pipeline.
  • All scans should be fully automated and kicked off automatically via APIs triggered by the developer’s CI/CD toolchain and process events
  • The scans should be tuned to reduce false positives, even at the expense of false negatives.
  • The results should be directly delivered into the bug tracking system or development dashboard, depending on the CI/CD toolchain and process used by the developers. Even better is to make sure the feedback is nearly instantanously so that security issues can be fixed directly instead of being added to a backlog. 

 

Start with Identification and Remediation of Known Open-Source Vulnerabilities

Modern software is often assembled, rather than developed. Developers make heavy use of prebuilt components, libraries, containers and frameworks from publicly available sources and repositories (such as GitHub, SourceForge, Maven and Docker Hub). Custom code often represents a minority percentage of the code in a modern application, to perhaps even less than 10% of the final application.

This means a shift in focus for security scanning, because most of the risk can be addressed by identifying known vulnerabilities and misconfiguration issues in these libraries, frameworks and components before they are put into production. From a security perspective, it is much easier to identify known vulnerabilities in known code than unknown vulnerabilities in custom code. This can be done in a variety of ways, in its simplest form, by matching files against a vulnerability database (like NVD). Vulnerability assessment vendors are adapting their scanning capabilities to address the need to do this automatically in DevSecOps, and some toolchain element vendors, such as Docker, are integrating this capability.

 

Implement a Simple Security Requirements Gathering Tool

For all new applications, we recommend a simple security requirements gathering and threat modeling tool to provide the developer an easy start. The goal should be selfservice wherever possible. For existing applications, consider an incremental approach to threat modeling, focused on major changes to applications.

The purpose of threat modelling must be clear from the start, so that when looking at the results, teams are coached in determining the priorities for making improvements. For instance this could mean; customizing a SAST/DAST setup.

For the high-risk applications however, we recommend engagement directly with the information security team via the liaison for full threat modeling and security requirements gathering.

 

Wrap up

With these initial measures, you grow buy-in for DevSecOps principles with developers. The purpose is to reach the starting point towards the next stage. This next stage will be all about achieving the culture of  You code it, you own it.

DevSecOps teams should ultimately perform the frontline monitoring for their services/products, spanning both operational and security monitoring. DevOps teams should be empowered to take responsibility for incident monitoring and their response strategy. They should be responsible for developing the response strategy to enable the organization to return to an acceptable level of performance in an acceptable period after a business disruption.

In one of our next posts, we will describe a series of measures to realise this stage.