Why do I need to do code review if my environment is secure

Question

Why do I need to do code review if for example I believe that my application’s runtime environment is secure, or for example my application has been running for 20 years and this activity has never been done before, etc.

Answer

First and foremost, our office does not determine authorization requirements; an IA analyst or ISO should be contacted for timing and applicability of authorization requirements if there is a non-technical question of applicability. Our office only performs activities only upon request, if other parties determine that doing so is appropriate.

That said, in short without going into details of FISMA requirements and so on, there are two basic reasons why code review is done at the VA:

1. From a technical perspective, the goal is to make applications themselves (as opposed to runtime environments) more resilient, more able to protect themselves against attacks.
2. From an authorization perspective, secure code review are now A&A / continuous monitoring requirements in the Accreditation Requirements Guide SOP.

Security-relevant features of the system that the application is deployed to are only relevant to secure code review activities insofar as they act as mitigations for specific findings in code, as identified using Fortify according to VA code review SOP.

For example, auditing an issue in a code review with a comment such as “my environment is secure, has been deployed for 20 years, etc.” will be rejected as an argument as to why it is thought that a finding is a false positive.

This is compared to, auditing an issue in a code review with a comment such as “access to the configuration file is restricted, the operating system on the production server is configured to set permissions according to VA hosting facility policy”.

See Also

How secure code review is different than exploit development