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: https://www.sans.org/reading-room/whitepapers/analyst/survey-application-security-programs-practices-34765
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
- 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:
|TOOL||LANGUAGES SUPPORTED||SUPPORTED CI/CD PLATFORMS|
|SonarQube||Java, .NET, Python, Ruby and many other languages||Jenkins, TeamCity, Microsoft TFS, Bamboo, Azure Pipelines|
|Checkmarx||Multiple Languages including Java and .NET||Jenkins, TeamCity, Microsoft TFS, Bamboo|
|Fortify||Multiple Languages including Java and .NET||Jenkins, Bamboo and some other tools through CLI|
|RIPS||PHP is the primary language supported||Jenkins, Bamboo|
|IBM Appscan||Multiple Languages including Java and .NET||Jenkins, TeamCity|
|Brakeman||Ruby on Rails||Jenkins|
|OWASP Dependency Check||Java and .NET fully supported. Other languages have some limited support||Jenkins|
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
|TOOL||APPLICATIONS SUPPORTED||SUPPORTED CI/CD PLATFORMS|
|Gauntlt||Web||Gauntlt can be set up within Docker containers and then integrated with Jenkins|
|BDD-Security||Web||Jenkins can trigger the BDD-Security Framework and analyze results|
|IBM AppScan||Web, Web services/API, Mobile||Jenkins|
|HP WebInspect||Web, Web services/API, Mobile||Jenkins|
We can construct a pipeline integrating these tools as shown below:
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.
- 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 firstname.lastname@example.org. Our experts will be delighted to engage with you. Also, you can visit Qentelli’s social links for more details– Facebook Twitter LinkedIn
Headquartered in Dallas, TX with global delivery teams in India, Qentelli is an Industry Thought Leader in Quality Engineering, Automated Testing and Continuous Delivery. With high performing engineering teams working in the dedicated Innovation Group, Qentelli brings design thinking to address complex business problems and enables Continuous Delivery across Enterprise IT through automation for its global customers.