Maintain software throughout its useful life

Give maintenance a service owner

Useful software continues to change after its first release. Dependencies receive fixes. Runtimes lose support. Certificates expire. Business rules change. Access granted during setup can remain longer than intended.

Keep an inventory of services, owners, deployed versions, dependencies, and support dates. Include scheduled work and work triggered by a new finding. Allocate capacity for both. A maintenance backlog without an owner does not protect the service.

Separate maintenance from immediate incident response. An exposed credential or evidence of active compromise can require containment before an ordinary development cycle finishes. Refer those cases to the security response process.

Prioritize the actual exposure

Severity describes potential consequences. Priority also depends on exploitation, reachability, data, existing controls, and the cost of delay. A low-traffic internal service can still hold important credentials.

CISA’s Known Exploited Vulnerabilities catalog records vulnerabilities with evidence of exploitation. Use this as a prioritization input. Absence from that catalog does not prove that a vulnerability is safe. CISA catalog.

Consider these fictional findings. The time limits belong to the example organization; they are not universal deadlines.

Do not automatically turn every finding into a major upgrade. Select a supported correction, inspect compatibility, and test the behavior that matters. Record temporary mitigations with an owner and an expiry condition.

Follow the correction into production

Use a traceable sequence: finding, decision, change, review, deployment, and verification. Record the artifact identifier that production actually uses. Re-scan the relevant artifact or environment after the change.

For a fictional vulnerable PDF package, a team merges an upgrade at 10:00. Production still runs yesterday’s image at 11:00. The repository correction is complete. Production remediation is incomplete.

After deployment, verify both the package version and PDF generation. A vulnerability scan cannot establish that the export still works. A functional test cannot establish that the vulnerable component has been removed.

NIST’s SSDF includes ongoing vulnerability identification and response. Apply those practices across the lifecycle, including software that receives few feature requests. NIST SSDF.

Use automation with visible limits

Taiga Maintaining scans linked repositories and can turn findings into remediation initiatives. Check the latest successful sweep, the affected version, and the resulting change. Repository scanning does not establish production reachability. Maintaining.

Automation can reduce repeated work, but the service still needs deployment ownership and verification. Keep release decisions, emergency access, and exception expiry explicit.

Maintenance also includes retirement. Remove unused routes, credentials, integrations, and infrastructure through a controlled process. Check retention requirements and dependent services before deletion. Retire the running service and assign any remaining retention or audit duties.

The next lesson covers continuous vulnerability scanning and remediation in detail.