Skip to content

Static Application Security Testing

Static Application Security Testing (SAST) is a method for analyzing application source code, byte code, and binaries to identify coding and design flaws that could lead to security vulnerabilities. SAST solutions analyze applications from the “inside out” in a non-running state.

SAST artifacts requirement

As part of our security screening, Second Front (2F) Systems requires SAST artifacts to be included in your application’s Authorization Package. These artifacts are critical to provide government accrediting officials with evidence needed to assess and approve your application.

SAST artifacts must be current—no older than 30 days prior to submission—and are required in the following cases:

  • Initial CtF: Your application has not yet received a CtF (Certificate to Field).
  • Renewal CtF: Your application is undergoing CtF renewal.
  • Significant change: Major updates since the last CtF will require reauthorization and a new CtF approved by the government accrediting official.
  • Ad-hoc requests: To meet continuous monitoring requirements.

Customer responsibility

As a customer, you’re responsible for ensuring the following tasks are completed to meet SAST requirements:

  • Conduct SAST scans on the source code repositories from which containers are built and deployed to Game Warden.
  • In each applicable System Security Plan (SSP), attest that the SAST report matches the deployed codebase.
  • Upload SAST artifacts to Game Warden.

In the Game Warden application, you can upload these artifacts and check the Attestation checkbox in the SSP. Accepted artifact formats are PDF, XML, HTML/HTM, or JSON.

SAST in SSP

SAST Acceptable Baseline Criteria

Second Front Systems uses a “Meets / Does Not Meet” framework to evaluate SAST reports, focusing on the OWASP Top 10 vulnerabilities and exposure of sensitive data (such as secret keys or plain text passwords).

  • Meets: No Critical/High vulnerabilities. All Medium/Low issues have documented justifications and remediation timelines.

  • Does Not Meet:

    • Critical/High vulnerabilities not remediated.
    • Medium/Low issues present without justifications or mitigation timelines.

SAST Acceptance Baseline Criteria severity table

Here are a few key points to keep in mind about severity levels and how they’re handled:

  • SAST scanning tools may use different severity levels and naming conventions.
  • For example, some tools might categorize vulnerabilities labeled as Critical under the High severity level. The 2F Security team can help clarify how these severity levels align with the tool you’re using.
Severity Remediation Actions Justification / Mitigation Remediation Plan
Critical Required: Must make every effort to remediate all critical vulnerabilities identified in the SAST scan. If remediation is not possible, see the note below for further guidance. Required (if remediation is not possible): Explanation of why the vulnerability cannot be remediated, along with mitigation measures or actions. Required (if remediation is not possible): Detailed timeline for implementing the vulnerability remediation.
High Required: Must make every effort to remediate all high vulnerabilities identified in the SAST scan. If remediation is not possible, see the note below for further guidance. Required (if remediation is not possible): Explanation of why the vulnerability cannot be remediated, along with mitigation measures or actions. Required (if remediation is not possible): Detailed timeline for implementing the vulnerability remediation.
Medium Recommended: Attempt to remediate all vulnerabilities. Required: Mitigation measures or actions must be provided. Required: Detailed timeline to implement the vulnerability remediation.

Note: Must be remediated within 60 days from the SAST acceptance date.
Low Recommended: Attempt to remediate all vulnerabilities. Required: Mitigation measures or actions must be provided. Required: Detailed timeline to implement the vulnerability remediation.

Note: Must be remediated within 180 days from the SAST acceptance date.

When remediation is not possible

Findings classified as Critical or High severity typically result in a "Does Not Meet" rating and require an immediate remediation.

If remediation cannot be performed, you must provide a written justification or mitigation plan, along with a proposed remediation timeline. These info will be reviewed by 2F Security team to determine whether the SAST artifact can be accepted under the "Meets" criteria.

SAST scanning tools

When selecting SAST tools suitable for government use, popular options include:

  • Checkmarx
  • Veracode
  • SonarQube
  • Fortify on Demand
  • Coverity

These tools provide robust security features, strong compliance capabilities, and support for government-mandated standards, making them well-suited for sensitive applications.

Example SAST tools: OWASP Source Code Analysis Tools.

Second Front Systems does not endorse specific vendors or tools.