Security is an ongoing way of working, not a feature to buy or a box to tick. A quiet incident history does not prove an environment is safe. Even systems without obviously valuable data can provide a route to third-party credentials or other targets. Build security into everyday decisions where possible; adding it later can be disruptive, but an existing platform can still be improved. section 12.0 section 12.6
Use three actions to guide the work:
- Identify what needs attention by continually evaluating the threat surface. Data categorization can help establish ownership, aging, and security requirements. section 12.0 section 8.9
- Protect systems beyond production. Separate the build process, restrict version-control access, and pin third-party library versions until upgrades have been validated. section 12.7.2
- Monitor systems for attacks or breaches, and investigate unexpected changes to deployment size. section 12.0 section 12.7.2
A trusted update can carry an attack
The SolarWinds attack illustrates why the build pipeline matters: malicious code introduced into widely used software reached other organizations through a normal update. Securing only the production environment would miss that route. section 12.7.2
Protect the copies of data as carefully as the live environment. A backup or archive can defeat multilayer access controls if it is broadly accessible. Someone responsible for running and validating backups does not necessarily need to read their contents; control access to the encryption keys accordingly. section 13.4.2
Ask whether shared passwords, long-neglected patching, missing recovery policies, or undocumented production systems point to a need for dedicated technical leadership. When a public breach raises questions, give colleagues a plain-language explanation they can use with customers rather than leaving them to interpret headlines alone. section 1.3 section 2.6.1
