A cloud-hosted internal application was released three years ago and is no longer actively developed, though it remains in production and processes employee data. Which secure SDLC activity is most important for it now?
Select an answer to reveal the explanation.
Short Explanation
Code doesn't rot, but the world around it does. New vulnerabilities get found in libraries you shipped years ago, so a 'finished' app still needs patching, watching and, eventually, a proper funeral. The trap is thinking no new commits means no new risk.
Full Explanation
The maintenance phase of the SDLC covers everything that keeps a released application secure while it remains in service. Its code may be stable, but the components it depends on, such as libraries, frameworks, runtimes and container base images, continue to have vulnerabilities disclosed, and the threat landscape and regulations change around it. Maintenance therefore includes tracking and patching dependencies, monitoring and vulnerability scanning, reviewing access, responding to incidents, and planning the eventual decommissioning, including secure data disposal such as crypto-shredding of its stored data. Re-running requirements gathering is how a new development cycle starts; it does not address the risk of the version already running in production. Leaving the application untouched assumes vulnerabilities come only from new code, when in practice many come from newly discovered flaws in existing components. Removing it from scanning removes the main way those newly disclosed flaws would be detected, which turns an unmaintained application into an invisible one. Exam caveat: the outline lists maintain alongside define, design, develop, test and deploy; secure retirement belongs to this phase, not to a separate process. Operational check: confirm the application has a named owner, appears in the software inventory and vulnerability scans, has dependency updates applied within policy, and has a documented retirement plan.