Which comes first? – The new stack

Altaz Valani

Altaz Valani is the Director of Insights Research at Security Compass. He conducts continuous research in the field of software security. Prior to joining Security Compass, he was Senior Research Director and Executive Advisor at Info-Tech Research Group, providing trusted advice on application development, application streamlining, agile, cloud, mobile and SDLC. Other previous positions include Senior Director at KPMG and other positions alongside high-level stakeholders to drive business value through software development.

Organizations face several choices when starting or maturing an application security program. They can implement secure coding training, hire penetration testing services, license scanning tools, or conduct design reviews and threat modeling exercises. Few organizations have the budgets and internal capabilities to do more than one or two at a time.

In today’s rapid deployment environment, the goal of any program should be twofold: reduce application weaknesses that could be exploited by a malicious actor, and maintain development speed by minimizing rework to mitigate vulnerabilities. late in the development life cycle.

This last objective cannot be minimized. Vulnerabilities and other weaknesses discovered late in the development lifecycle are much more expensive to fix. While refactoring later in the lifecycle slows releases, it also increases friction between security and development. The solution is to avoid these problems by moving to the left and integrating security activities into the early stages of the development process.

Understand your options

As teams consider their choices for improving software security, there is no shortage of software security categories. During the development process, static application security testing (SAST) and interactive application security testing (IAST) promise to identify coding errors that can lead to vulnerabilities. Software Composition Analysis (SCA) and a software BOM can be mapped to a database of known vulnerabilities in those components (or licenses that could put intellectual property at risk).

Many of them integrate into the build server to automatically analyze code or into developers’ integrated development environments (IDEs) to move further left.

Application Security Orchestration and Correlation (ASOC) tools help teams coordinate their scans, consolidate vulnerability findings, and prioritize mitigations.

Later in the lifecycle, dynamic application security testing (DAST) tests running applications to identify problems. Once applications are deployed, additional solutions are available, including web application firewalls, security solutions for containers and Kubernetes, and tools designed to secure the development environment itself.

Where to Focus First

The relative cost of patching vulnerabilities leads many organizations to opt for earlier testing. After all, finding weaknesses earlier saves time and money. While scanning is a good exercise, it shouldn’t be an organization’s primary security activity.

Avoid developer rejection

A good security program requires the support of software engineering teams. When maturing a software security program, the needs of a development team must be considered. It starts with how these teams are typically evaluated: delivering a defined set of features by a specific date.

Delays are common when security scanners are added to the development process. The output of the analytics tools produces three artifacts that developers have to deal with:

  • True Positives: exploitable weaknesses requiring remediation
  • False positives: errors in results, including incorrect reporting of weaknesses
  • Informative/insignificant issues: Results of “effective false positives” related to style rules or low priority issues that do not present a significant risk.

The National Institute of Standards and Technology (NIST) studies of static analysis tools have found that the latter two categories comprise most of the reported issues. The combination of False positives and Trivial issues ranged from 40% for Java applications to 68% for C applications.

It is usually the responsibility of development to determine the appropriate category for each result of a scan. This “triage” effort takes time. Too much False positives and Informative or trivial issues cause unnecessary developmental delays.

Search by GrammaTech found that triaging a single result – regardless of category – takes an average of 10 minutes. In other words, triaging just 240 issues takes 40 hours – a week of work – of effort. When everyone wants to approach True Positiveswhen these account for barely half of the problems generated by a scanner, pushback is inevitable.

Proactive security is a better approach

Testing for weaknesses after writing code is reactive. A better approach is to anticipate weaknesses before code is written and assigns mitigation controls as part of the development process. This is accomplished by security requirements.

Just as functional requirements provide teams with information about the functionality and performance needed in a project, security requirements provide teams with the controls necessary to mitigate the risk of potential weaknesses before coding begins.

Most of these weaknesses are predictable based on regulatory requirements in the scope of the application as well as the deployment language, structure, and environment. By translating them into mitigating controls — actionable tasks for product development, security, and operations teams to implement during the normal development process — teams can build more secure software and avoid a large part of the “find and correct” delays they are currently experiencing.

With comprehensive security requirements and appropriate mitigating controls as part of the overall project requirements, security is built in as the application is developed. Weaknesses can be avoided and security changes left as much as possible. Security testing becomes a tool for validating that prescribed controls have been implemented correctly instead of acting as a primary vulnerability discovery activity.

Instead of just testing for weaknesses, a more effective software security program prevents them. This requires a streamlined and automated approach to providing precise and concise requirements before coding begins.

Feature image via Pixabay.