When should static code analysis ideally occur?

A.  Before compilation

B.  During a live attack

C.  During runtime

D.  After decommissioning the code

Correct Answer:  A

Explanation:

A. Before Compilation
Static Code Analysis (also known as SAST - Static Application Security Testing) involves examining the source code, bytecode, or application binaries without actually executing the program.

Why it's the Answer: SAST is a "white-box" testing method that looks at the "blueprint" of the software. By analyzing the code before it is compiled or run, developers can find structural vulnerabilities—such as hardcoded passwords, buffer overflow risks, or SQL injection flaws—at the earliest possible stage.

The "Shift Left" Connection: Performing SAST before compilation is a key part of the "Shift Left" strategy. It allows for immediate feedback to developers, significantly reducing the cost and effort required to fix security bugs compared to finding them later in the testing or production phases.

B. During a Live Attack
A live attack requires Incident Response and active defensive measures, not code analysis.

The Priority: When an application is under attack, the focus is on Detection and Containment. While code analysis might happen after the attack as part of a "Lessons Learned" phase to find the flaw the attacker used, it is not an ideal or effective activity to perform while the breach is in progress.

Relevant Controls: During an attack, you would rely on WAFs (Web Application Firewalls), IPS (Intrusion Prevention Systems), and SIEM alerts rather than scanning source code.

C. During Runtime
Testing that occurs while the program is running is known as Dynamic Analysis (or DAST - Dynamic Application Security Testing).

The Distinction: Dynamic analysis is a "black-box" approach that tests the application from the outside in its functional state. It is excellent for finding issues that only appear when the code interacts with a real environment (like session management flaws or server configuration issues).

The Methodology: Because Static analysis is defined by its "non-running" nature, performing it during runtime is a contradiction in terms.

D. After Decommissioning the Code
Decommissioning is the final stage of the Software Product Life Cycle, where the application is formally retired.

The Purpose: Security at this stage focuses on Data Retention and Safe Disposal (ensuring sensitive data is wiped and the system is not left as an "orphan" or "shadow IT" risk).

The Irrelevance: Once code is decommissioned, it is no longer running or supporting business processes. Analyzing its source code for vulnerabilities at this point provides no defensive value, as the "attack surface" has already been removed by the act of decommissioning.

Key Takeaway for the CISSP Exam
Testing Cheat Sheet:

• Static Analysis (SAST): Inside-out. Checks source code/binaries. No execution required. (Before compilation).
• Dynamic Analysis (DAST): Outside-in. Checks running application. (During runtime/testing).
• Fuzzing: Sending random/malformed data to a running app to cause a crash. (Dynamic).