Menu
In this article, we’ll run through what software development typically looks like for enterprises in 2021, how security tools and processes can, are and should be integrated, and what features to look for to best leverage current approaches to support the development process.
Wondering what SDLC is? Start here: SDLC Explained
Devops grew from a small number of early practitioners to be 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 artifacts – 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 an established dynamic testing phases, consisting of automated tools such as Behat or Selenium 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 a 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:
[Image by Falkor]
Some actions will act as quality gates either permitting or denying the code candidate progress (eg if tests are failed) whereas others may apply standard transformations to the artifact, such as stripping it of metadata, compiling it, submitting it to a repository, or deploying it to a 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.
AppCheck offers a specific integration with JetBrains TeamCity build management and continuous integration server, as well as an API that can be used to configure, trigger and query scan results from all other major CI/CD pipeline tools.
Once your scan has completed, it’s important to know the outcome and to be able to use this for intelligent decisioning. AppCheck provides numerous integration methods including posting of scan outcomes to a webhook, and API polling for scan completion and results delivery. However AppCheck also offers specific integration with the Atlassian JIRA system to deliver findings as tickets into a customer JIRA Cloud ticketing system, to support integration with customer’s own ticket system, where they can be assigned for analysis and remediation as needed.
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.
AppCheck supports methods including the restricting of scanning to defined user journeys only. Our custom GoScript allows you to define specific customer journeys to be scanned, delivering similar tightly focused testing to that under systems such as Behat and Selenium and delivering greater scanning efficiency and faster time to delivery.
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 artifacts 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.
If you’d like any further information or would like to see what vulnerabilities we can pick up in your web applications then feel free to email us at info@appcheck-ng.com where an AppCheck representative can set up your free vulnerability assessment.
No software to download or install.
Contact us or call us 0113 887 8380
