Skip to main content
February 4, 2013

The Changed System, Threat and Regulatory Landscape

Are You Managing Your Code Quality?For our government readers. I want to briefly draw your attention to the newly signed Department of Defense National Defense Authorization Act (NDAA) of 2013 and the revised Federal Information Security Management Act (FISMA). FISMA compliance is based on the National Institute of Standards and Testing 800-53 Special Publication series (NIST SP 800-53). In the most recent version NIST SP 800-53 addresses software supply chain risk – and explicitly calls for static and dynamic testing for application security. The FISMA regulations are “doubling down” on risk-based threat mitigation and continuous application monitoring or diagnostics, as opposed to static, functional audits. The over-arching goal: application security assurance. Separately, static code analysis such as that performed by Veracode is also highlighted in the newly signed Department of Defense National Defense Authorization Act (NDAA) of 2013. The revised NIST SP 800-53 acknowledges the changed threat and application landscape with detailed guidance for and greater emphasis on system security assurance and continuous monitoring. In addition to static, dynamic, and penetration testing controls for complex, internally developed applications, NIST SP 800-53 now requires controls for the extended software supply chain. More detailed and proscriptive requirements are spelled out in the System and Services Acquisition family of controls. Fundamental to application security is Developer Security Testing (SA-11), which expands the scope of controls well beyond testing individual security features and functions. Developer Security Testing requires an application security test and evaluation plan that covers design, specifies unit through integration and regression testing (11.6), and importantly, requires independently verified “evidence of the testing/evaluation plan” (11.3). Additional sub-sections reinforce the new expectations for application security assurance:

  • Code Analysis Tools (11.1) which specifies static and/or dynamic testing to search for and document common application flaws;
  • Guidance for system developers for threat and vulnerability testing – and fixing – in Flaw Remediation (11.2);
  • Manual Code Reviews (11.4), reserved for the critical software and firmware;
  • Penetration Testing (11.5);
  • Attack Surface Reviews (11.7): how can I reduce my attack surfaces;
  • Verify Scope of Testing (11.8), different than independent verification, a control on the coverage, the scope of the security testing.

For the first time, controls for the software supply chain are specified in section 12, Supply Chain Protection. Supply Chain application security assurance is focused on the integrity of the acquisition, delivery and acceptance of externally developed code. The key control is Assessments Prior to Selection / Acceptance / Update (SA-12.7). Hereto the guidance specifically identifies static and dynamic testing, as well as other types of testing, but focuses on the evaluation and delivery processes of externally sourced software “prior to selection, acceptance, or update.” The software security assurance goals of the sub-sections are self-evident:

  • Operations Security (12.9);
  • Unauthorized Modifications (12.10);
  • Validate as Genuine and not Altered (12.11);
  • Penetration Testing / Analysis of Supply Chain Elements (12.12);
  • Processes to Address Weaknesses or Deficiencies (12.15).

To learn more read the FISMA Compliance Simplified fact sheet.

Fergal Glynn joined Veracode in 2008. Fergal is currently responsible for lead generation activities including content marketing, blogging, search engine optimization, webinar marketing, social media, and optimizing the marketing and sales funnel. Fergal spent his first two years at Veracode as a Product Manager.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.