Skip to main content

About application risk management

Veracode is the only on-demand provider that offers a full application risk management solution. This solution includes an application inventory definition and an application security policy that provides multiple analysis methods and standard security ratings.

Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support their organizations' missions. Overall risk management encompasses three processes: risk assessment, risk mitigation, and evaluation and assessment. The tasks in this section detail best practices for implementing a successful software risk management program.

Task 1: Assess business criticality across the application portfolio

While it might seem obvious that as part of a risk assessment organizations need to create a portfolio of their applications that are being developed, purchased, or maintained by an outsourcing provider, in practice it is a challenging exercise. With the advent of low-cost offshore development, open source and low-cost commercial software it is common to see application "sprawl" as individual groups or business units might have contracted work that previously would have required higher capital costs and formal approvals. During an application inventory, include business units, procurement, and vendor management to identify all software that has entered or is entering the organization.

Once applications have been identified, organizations need to understand the risk that the application poses to the business. This can be achieved through the assignment of a business criticality for each application based on business risk factors, such as:

  • Reputation damage
  • Financial loss
  • Operational risk
  • Sensitive information disclosure
  • Personal safety
  • Legal violations

Business criticality determines the extent of testing methods. More critical applications might require multiple testing techniques, while lower criticality applications might be accepted with lower security scores because they pose less risk to the business.

Task 2: Define application security policies

The business criticality selected for an application determines the application security policy required for the application. Defining an application security policy consists of these steps:

  1. Select appropriate analysis methods and scanning frequency
  2. Use industry standard security scores
  3. Define appropriate remediation periods
  4. Set policies for acceptable thresholds
  5. Select an appropriate application to scan

Select appropriate analysis methods and scanning frequency

Applications with higher business criticality require more comprehensive analysis for Veracode to accurately score their security quality. Each analysis method—(automated static, automated dynamic, manual penetration testing or manual review)—has a different false negative (FN) rate for various security flaws. A single technique or a combination of techniques will still result in some false negatives. For lower business criticality applications, a certain level of false negatives is acceptable, making it feasible to use fewer and less costly analysis methods. However, for applications with higher business criticality, the false negative rate should be as close to zero as possible. Veracode, therefore, recommends using multiple analysis techniques.

In this image, higher business criticality applications require multiple testing techniques to maintain an acceptable level of risk to the organization:

As an application’s business criticality increases, multiple analysis techniques should be used to ensure a more accurate assessment of its security quality.

Use industry standard security scores

Until recently, security solution providers used proprietary systems to assess the severity of vulnerabilities. This lack of standardization led to discrepancies between products and services, reducing the value of security assessments. In 2005, a coalition of security experts developed the Common Vulnerability Scoring System (CVSS)—a vendor-agnostic standard for evaluating vulnerability severity. CVSS helps businesses prioritize which flaws to fix.

Veracode integrates CVSS severity ratings and exploitability scores with other industry standards, such as the MITRE Common Weakness Enumeration (CWE), which classifies software weaknesses. This combination provides a comprehensive application security rating. Veracode is the only organization that merges these standards into a unified framework for evaluating software security across both internally and externally developed applications.

To determine a Security Quality Score (SQS), Veracode aggregates all detected security flaw severities and normalizes the result to a 0–100 scale, where 100 represents a perfect score. To compute the Veracode Level for each testing technique, Veracode then factors in the type of testing performed (automated static, automated dynamic, or manual) and the application’s business criticality .

Set policies for acceptable thresholds

The overall Veracode Level (1–5) depends on the Security Quality Score (SQS), severity of detected flaws, and completed scans. This allows businesses to establish policies for acceptable thresholds based not only on the number and severity of vulnerabilities in the software but also on the risk the application poses to the business.

The type of testing performed on the application, along with the severity and types of detected flaws, determines its Veracode Level (VL). Each VL requires a minimum security score.

Select an appropriate application to scan

To determine which applications to scan, review supported languages and platforms for Static Analysis and guidelines for Dynamic Analysis scans.