1. Dependencies are part of your infrastructure
A library is not only code you import. It is a maintenance relationship. If a dependency becomes vulnerable, abandoned or incompatible, the business may inherit that risk.
Small teams do not need enterprise bureaucracy to manage dependencies. They need visibility, update routines and a way to know which systems are affected.
- Know which dependencies are used in each project.
- Avoid adding libraries for small tasks without review.
- Track security advisories for critical stacks.
- Update gradually and test critical flows.
- Remove packages that are no longer needed.
2. Secrets and access are common weak points
Many incidents do not begin with sophisticated attacks. They begin with exposed tokens, shared passwords, old vendor access, credentials in repositories or environment variables copied without control.
Security improves when ownership is explicit: who can deploy, who can access production, who owns DNS, who owns email, who owns API keys and how access is removed.
- Never commit secrets to the repository.
- Rotate tokens after accidental exposure.
- Use environment variables or secret managers intentionally.
- Remove access when vendors or employees leave.
- Document ownership of DNS, hosting, email, repositories and ad accounts.
3. SBOM and inventory make risk searchable
A software bill of materials is an inventory of software components. Even a simple dependency list helps answer an urgent question: are we affected by this vulnerability?
For small systems, the first inventory can be lightweight: project, language, framework, runtime, major dependencies, hosting, database and owner.
- Keep a dependency inventory for important systems.
- Record runtime versions such as Java, Node and database.
- Know which container images are used in production.
- Link inventory with repository and deployment documentation.
- Review the inventory after major updates.
4. Security needs a routine, not panic
Security work becomes more realistic when it enters maintenance: updates, backups, access review, dependency checks, logs, incident notes and restore tests.
The goal is not perfect security. The goal is reducing avoidable exposure and making incidents easier to detect, contain and recover from.
- Schedule dependency and access reviews.
- Keep backups and restoration steps testable.
- Use logs that help detect suspicious behavior.
- Create a small incident response playbook.
- Treat security as part of operational continuity.
How to use this article
Treat this page as a decision aid. Use it with the related hub, checklist or service route when the topic affects production, customer experience, deployment, security or business continuity.