The following blog post was written by our friends at AppCheck, where they take a look at how security tools and processes can, are, and should be integrated, as well as what features to look for in order to leverage current approaches to support the development process.
DevOps grew from a small number of early practitioners to being more widely adopted. It can be loosely defined as a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality. Typically it provides a significant focus on factors such as automation, the definition and management of all artefacts – including infrastructure components – as code, and continuity of delivery.
There is no single toolchain established for DevOps, but typically tools and workflows exist for 7 areas that loosely align with the stages of a typical SDLC model:
A commonly encountered commercial toolchain built around the DevOps model is Azure DevOps Services, which offers specific components including Boards (ticket management), Pipeline (CI/CD), Test Plans (continuous testing) and Repos (code management).
SecDevOps (also known as DevSecOps or DevOpsSec) is the process of integrating secure development best practices and methodologies into the development and deployment processes which DevOps makes possible.
At a high level, this involves a simple mapping between each SDLC stage and a recommended “best practice” approach to how security is best covered within that stage. Dynamic Analysis (DAST) tools, also known as Vulnerability Scanners, such as AppCheck, are typically recommended as the most suitable controls for the “Test” stage of existing pipelines.
Many mature SDLC pipelines will typically have established dynamic testing phases, consisting of automated tools that provide testing for functional expectations by making HTTP requests to a test or staging deployment of an application. In these scenarios, integrating Secure SDLC practices at the Testing stage simply involves extending this phase of testing to include non-functional (security) tests. The building of security into the tools that exist in the DevOps pipeline is typically referred to as “Security as Code (SaC).”
In a Secure SDLC, every build delivered by the development team is immediately scanned in real-time for issues and the developer is notified about issues that they need to correct. So how is this typically delivered?
Many organisations will perform a process known as Continuous Integration, the practice of merging all developer working copies to shared mainline several times a day. This is typically coupled with:
The tool that ties together all these processes is known as a pipeline and is generally delivered as an automation server that permits an organisation to model and develop an automated workflow. Rather than a pipeline, it might help to think of this defined workflow as something more like a Rube Goldberg machine – a code candidate is submitted at the start of the workflow and is processed by a number of tools in sequence, which perform defined pre-determined actions.
Some actions will act as quality gates either permitting or denying the coding candidate progress (e.g., if tests are failed) whereas others may apply standard transformations to the artefact, such as stripping it of metadata, compiling it, submitting it to a repository, or deploying it to production or non-production system.
If you are looking to establish an SDLC pipeline under a DevOps framework, or else already implement a CI/CD pipeline and are reviewing candidates for DAST scanning of code deployed to a pre-production instance, then the following feature set is important to consider when evaluating candidates:
A fundamental pre-requisite is that your chosen DAST tool must support integration with your chosen CI/CD pipeline so that you can configure for scans to be triggered automatically once a build is delivered to a test or staging environment.
Once your scan has been completed, it’s important to know the outcome and to be able to use this for intelligent decision-making. AppCheck provides numerous integration methods including posting of scan outcomes to a webhook, and API polling for scan completion and results delivery.
If you fix one issue, you don’t want always to retest your entire application. It is possible to integrate AppCheck with your issue tracking systems so that issues are automatically retested after being closed by the developer.
AppCheck web application scanner is highly configurable, with scans able to be configured via API or GUI to use one of a number of existing scan profiles or to define customer-specific scan profiles. If you know that your application uses specific languages and platforms, enable scanning using relevant plugins only, reducing scan times and customising scanning for your specific application for greater scan result accuracy and faster delivery of scan completion and results.
If a specific code release only changed the code in a specific area of an application, why scan the whole thing? You can save time if your chosen DAST solution enables you to scan only specific portions of your application code that have changed, versus scanning the entire application.
Does your chosen DAST solution allow you to scan your platform at both the infrastructure and web application vulnerability layers? If your developers are producing web application code and your operations engineers are deploying artefacts via Infrastructure As Code (IaC) then it makes sense to pick a DAST solution capable of scanning both, automatically, when a deployment of either occurs.
Cantarus is a proud AppCheck Partner
If you’d like to know more about AppCheck you can visit their website, or get in touch with us at [email protected] to learn more.
