Bridging the security gap in the software development life cycle

security meter

The timeliness of security checks during the software testing process is critical to more rapid and higher quality software development and yielding higher returns. Yet DevOps and security have historically struggled to integrate in the software development life cycle (SDLC). According to a Gartner study, through 2022, 90 percent  of software development projects plan to follow DevSecOps practices, up from 40 percent  in 2019.

With the increased risks of cyberattacks and pressure on DevOps teams to deliver software to faster timelines, the risks and consequences associated with flawed code and faulty infrastructure configurations cannot afford to be missed in the early development stages. So the pros of uniting these teams is clear, but the cons remain costly and their discord could hold organizations back by making software deployment faster but in doing so releasing security vulnerabilities.

Why Security testing is a vital part of the SDLC

The modern DevOps framework of security is an integral part of the automated testing process to help with verifying compliance requirements in the preliminary development stages. Conducting post-development security checks carries an increased risk of vulnerabilities.

Security automation can expedite software delivery, while minimizing the risk of security threats — which can cause disruption and setbacks of months to aggressive timelines. In fact a Progress survey reveals that security automation not only speeds up software delivery but also improves quality. DevSecOps adopters are three times more likely than non-adopters to see security as something that speeds up software delivery and the majority of organisations (84 percent) agree that quality is also improved.

Without the mitigation of security, the gap will continue to grow as the software moves further along if it is not addressed immediately. Speed in innovation is nothing without security in the SDLC. In an era of rapidly developing threats and continually evolving compliance frameworks, it’s becoming more alarming that it can take weeks and even up to two months to remediate these violations or vulnerabilities.

“Everything as code” has the answer

Using everything as code across elements of compliance policies, infrastructure, and application dependencies can bridge the gap between teams in the software development life cycle by allowing different teams to share, scale and automate. Specific tests can make it accessible by various parties, such as security engineers, auditors, and systems administrators.

Shift-left testing can build security earlier on into the process which minimizes the pre-production error rate. This means that developers are more involved in workflow and invested in the process. Defining everything as code enables all teams to assess the software’s cybersecurity strength and can address any changes needed to ensure features are compliant.

A best practice approach

Here are four checks to ensure best practice for the SDLC integration with security to enable developers to be more agile and efficient:

Define compliance as code to be referenced as a clear and understandable concept which is scalable for all teams use:

Create customized policies — Enabling worker capabilities for rapid writing of custom policies, or building on existing, “desired state” policies in high-level and domain-specific languages (DSL).

Infrastructure-as-code (IaC) — Providing infrastructure configurations that are consistent with a compatible format for version control systems (VCS). This should enable peer code review, version control, change auditability, automated testing and deployment via CI/CD processes and tooling.

 Limit human interference during review and testing stages to minimize errors:

Rollback / grace period — It is important to define a grace period within which urgent configuration changes can be undone, for when configurations might have been changed directly on the server.

Set regular checks for secure coding practices for managing gap analysis and threat modelling — and ensure you build a checklist of security risks:

Workflow / case management tools — Ensure workflow tools are integrated. Such as ServiceNow, Jira, and webhooks. This will enable urgent manual intervention to address any compliance deviations.

Exception management — Enabling those same built-in workflow tools for exception management, allowing approval/review of individual deviations from desired state configuration, two-person rule observations and CI/CD pipeline visibility.

4. Confirm a set of security baselines which are easily customizable, for instance CIS Compliance Benchmarks and DISA STIGs:

Configuration drift — Chef is an ideal tool for customers to offset any configuration drift issues, as it prevents server deviation from a desired state (known-good) state. Hosts can fix issues by detecting configuration drift and performing automated remediation.

Monitor configuration — It’s advisable to use IT automation software to detect and manage the configuration on many different servers (Linux and Windows), ranging from physical to virtual machines.

Security automation and defining “everything as code” is the best way to address the compliance issue by bridging the security gap in the SDLC. This shared common language among teams is the source of truth that can be used to codify infrastructure configuration, security, and compliance.

Image Credit: donscarpo / depositphotos.com

Heather Peyton is a Product Marketing Director at Progress responsible for messaging around the Chef Enterprise Automation Stack. Prior to Chef Heather held DevOps related positions at CA and Worksoft. Heather started her tech career working for CompuCom, a large VAR/SI, where she focused on helping large organizations evaluate and deploy new and transformative technologies.

Author: Martha Meyer