Verification Scans or Automated Security Requirements: Which Comes First?

Organizations face several choices when starting or maturing an application security program. They can institute 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 of these at a time.

In today’s rapid deployment environment, the goal of any program must be two-fold: reduce weaknesses in applications that could be exploited by a malicious actor and maintain development velocity by minimizing rework to mitigate vulnerabilities late in the development life cycle.

The latter goal cannot be minimized. Vulnerabilities and other weaknesses discovered late in the development life cycle are far more expensive to remediate. While reworking later in the life cycle slows releases, it also increases friction between security and development. The solution is to avoid these issues by shifting left and building security activities into early phases of the development process.

Understand Your Options

As teams look at their choices for improving software security, there is no shortage of software security categories to choose from. During the development process, Static Application Security Testing (SAST) and Interactive Application Security Testing (IAST) promise to identify coding errors that can result in vulnerabilities. Software Composition Analysis (SCA) and a software bill of materials can be mapped to a database of known vulnerabilities in those components (or licenses that might put intellectual property at risk).

Many of these integrate with the build server to scan code automatically or into developers’ integrated development environments (IDE) to shift further left.

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

Later in the life cycle, Dynamic Application Security Testing (DAST) tests running applications to identify issues. 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 to remediate 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 should not be an organization’s primary security activity.

Avoiding Developer Pushback

A good security program requires support from the software engineering teams. When maturing a software security program, the needs of a development team must be considered. This starts with how those 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 scanning tools produces three artifacts with which developers must contend:

• True Positives: exploitable weaknesses that require remediation
• False Positives: errors in the results including incorrect reporting of weaknesses
• Informational/Insignificant Issues: “effective false positive” findings related to style rules or low priority issues that do not pose significant risk.

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

It typically falls to development to determine the appropriate category for each finding from a scan. This “triage” effort takes time. Too many False Positives and Informational or Insignificant Issues cause unnecessary development delays.

Research by GrammaTech found that triaging a single finding — irrespective of category — requires 10 minutes on average. In other words, triaging only 240 issues requires 40 hours — a workweek — of effort. While everyone wants to address True Positives, when these make up barely half of the issues generated by a scanner, pushback is inevitable.

Proactive Security Is a Better Approach

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

Just as functional requirements provide teams with information on the features and performance needed in a project, security requirements provide teams with required controls to mitigate risk from potential weaknesses before coding begins.

Most of these weaknesses are predictable based on the regulatory requirements in scope for the application along with the language, framework, and deployment environment. By translating these into mitigation controls — actionable tasks to be implemented by product development teams, security and operations during the normal development process — teams can build more secure software and avoid much of the “find and fix” delays they currently endure.

With complete security requirements and appropriate mitigation controls as part of the overall project requirements, security is built-in as the application is developed. Weaknesses can be avoided and security shifts left as far as possible. Security testing becomes a tool for validating the prescribed controls were 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, automated approach to delivering precise, concise requirements before coding begins.