Skip to main content
Page Tittle
Getting Started with DevSecOps
Getting Started with DevSecOps

If you ask CIOs or even CEOs what keeps them up at night, chances are that most of them will respond with ‘Security Breaches”.

IT Security has become a game of continuous one-upmanship on both sides of the fence – attackers are finding new ways to get into systems, while defenders are innovating to stop them before they do.

How can developers and testers help to improve the security posture to at least some extent? The answer is “baking” security into the application development process.

Web applications have a much lower risk profile with improved firewalls and access controls being deployed, but they continue to be a large attack vector – large enough to dedicate time and money to reduce risk.


An alarming fact published by Veracode is that about 75% of all applications have some security vulnerability that could be exploited!Source: State of Software security – A Developer’s Guide 2017 by CA Veracode

Kaspersky Labs found that 90% of Enterprises had a security breach in a quarter, with the potential financial impact on an average of $550KSource: Damage Control: The Cost of Security Breaches by Kaspersky Labs 2018


Comparing OWASP Top 10 from 2013 to the 2017 version (latest version), it is surprising that the Top 2 vulnerabilities are persisting. The next 3 are also issues that point to lack of security coding practices and automated security testing.Source: OWASP Top 10


With so much data available on the vulnerable areas and business impacts, are companies doing more frequent security testing for their apps? Apparently not.Source:…

The Solution: DevSecOps

DevSecOps is not a new concept, but for companies that have started or just starting with DevOps initiatives, it makes good sense to include Security testing within their build and test pipelines from the start.

With Dev teams using open-source and proprietary libraries, cloud, micro-services, containers etc. joining the product technology landscape, each of these components bring along their own set of security challenges into the overall product architecture.

How can Engineering teams start with integrating security tests within DevOps?

Teams can start using the 3 layers of application security integration in the Development process:

  • Secure coding standards
  • Integrating Static Application Security Testing (SAST) tools in Developer Builds
  • Integrating Dynamic Application Security Testing (DAST) tools in QA Builds

Let’s take a closer look at these layers and how you can integrate them into your Development process for overall security around your application stack –

Secure Coding Standards

It all starts with the code - Unsafe coding practices can result in vulnerabilities in application software that can be difficult to detect and expensive to fix later in the lifecycle. OWASP, SEI, NIST and several other Standards organizations and private companies publish secure coding guidelines covering all major programming languages.

These practices cover all development areas, for example:

  • Input Validation
  • Authentication and Authorization Management
  • Credentials Management
  • Session Management
  • Access Control
  • Encryption of Data at rest and in Transit
  • Resource Management

Integrated Development Environments (IDEs) are used by almost every developer, so plug-ins have been developed for these IDEs that can assist Developers in identifying and fixing errors when writing source code. Some of these tools include SecureAssist, GreenLight, ASIDE, FxCop, FindBugs.

Static Application Security Testing (SAST)

There are multiple tools available that can automate static code analysis rules during the build process and prevent developer branch from merging with the baseline repository. Some of the validations that can be performed at this stage include:

  • Software Component Analysis for identifying issues in third-party libraries and packages
  • Secure coding guidelines for the specific language
  • Unpatched libraries – when more recent versions of libraries are available, but not included in the source code calls
  • Injection – although more well-known for SQL calls, Injection vulnerabilities can occur in API calls or even Javascript
  • Unreleased Resources – DB connections, object references, data collections etc., may not have been released in the code, potentially leading to Denial-of-Service (DoS) attacks
  • Improper Error-handling – Developers may insert messages during development for easier debugging and may miss removing them when promoting code to higher environments. Another common mistake is not having a catch-all Error handling mechanism, that can provide a useful error message without revealing the technical details of the OS, Servers, language etc)

Some common SAST tools that integrate with CI Pipelines are:





Java, .NET, Python, Ruby and many other languages

Jenkins, TeamCity, Microsoft TFS, Bamboo, Azure Pipelines


Multiple Languages including Java and .NET

Jenkins, TeamCity, Microsoft TFS, Bamboo


Multiple Languages including Java and .NET

Jenkins, Bamboo and some other tools through CLI


PHP is the primary language supported

Jenkins, Bamboo

IBM Appscan

Multiple Languages including Java and .NET

Jenkins, TeamCity


Ruby on Rails


OWASP Dependency Check

Java and .NET fully supported. Other languages have some limited support


Dynamic Application Security Testing (DAST)

As the name implies, DAST tools find security issues when the application interacts with other system components like web services, DB and third-party components. In short, these tools run checks that simulate an external attacker trying to gain entry through the application.

Due to the dynamic nature of the applications, DAST tools are not 100% effective in uncovering security issues, but they can provide a very effective line of defense. Most common vulnerabilities have already been identified and included in these tools, so only very smart hackers can find issues after these tests are run.

Some of the core validations that DAST tools can perform include:

  • Application Penetration Tests
  • Production Deployment Configuration Tests
  • Injection tests
  • Session Management
  • Cross-Site forgery
  • Data at Transit issues

Common DAST Tools that integrate within the CI-CD Pipeline include









Gauntlt can be set up within Docker containers and then integrated with Jenkins



Jenkins can trigger the BDD-Security Framework and analyze results

IBM AppScan

Web, Web services/API, Mobile


HP WebInspect

Web, Web services/API, Mobile


We can construct a pipeline integrating these tools as shown below:

Getting Started with DevSecOps constructing a Pipeline

Note: The Tools shown are for illustration only – the actual toolset will depend on your environments, platforms, budget, Risk profile etc.

Key Point: To increase the security Test footprint, you may have to write custom tests (using selenium or similar tools). These could cover areas such as:

  • Duplicate session validation
  • User Authorization tests
  • HTTP Header spoofing

Key Point: The results generated by all of the tools are NOT uniform, with the result that you may have to review multiple reports, logs etc to get an overall picture. For example, Jenkins can call HP Fortify, but the tool results are not reported back to Jenkins.

To summarize:

  • Your applications and data are under constant attack. A breach can cause a very serious financial and reputational loss for your business and, increasingly, for you personally (due to US & European Regulations)
  • There is no magic fix for security. Instead, a defense-in-depth strategy starting from the application level and comprised of multiple tools, processes, and practices is much more resilient and effective
  • Leverage automation where you can, particularly for software testing
  • Integrating Automated security tests into your DevOps pipeline is becoming easier with modern tools

How can Qentelli help:

Qentelli works with some of the world’s largest companies to implement Automation across the lifecycle and has pioneered use of DevSecOps in these Engagements. Qentelli also has a custom-built Engineering Dashboard, TED, that can pull results from any software product which exposes such data through an API.

TED can be used to review metrics from the entire DevSecOps toolchain to get a complete view of functional and non-functional test results.

To learn and explore more in detail about Qentelli’s AI-driven automated testing solutions and DevSecOps implementations, please write to us at [email protected]