A website depends on software you did not write: plugins, libraries, themes, and build tools. Each dependency becomes part of the system’s risk. The useful starting point is the exact version and configuration you deploy, not just a product name in a spreadsheet.
Understand the idea
Identify who owns each dependency and how it reaches production. Check support status, update routes, available security notices, and what privileges it receives. A plugin that is installed but unused can still need attention. A test result for one version does not automatically cover a later build.
- Selection
Confirm the project and the required function.
- Deployment
Record the exact component, version, and authority.
- Maintenance
Track advisories and verify updates in your own environment.
A practical example
For example, an NGO’s website has a form plugin that nobody remembers installing. It is no longer needed, but still runs on the public site. The maintainer checks its use, removes it through the normal change process, and tests the forms that remain.
What to do next
- Choose a trustworthy source. Use the vendor's official distribution or a recognized registry. Verify package names and publisher information to avoid lookalikes.
- Review changes and support. Check relevant advisories, release notes, compatibility, and whether the component is maintained. Automated scanner output needs triage rather than automatic dismissal or panic.
- Limit build privileges. Keep production secrets out of untrusted jobs. Review permissions of build services and third-party actions.
- Test and record the release. Use a representative environment, preserve the previous working version, and record the exact deployed components.
- Plan the emergency path. Name who can disable, replace, or roll back a harmful release and how users will be informed.
How to check the result
Keep an inventory tied to the deployed release. After an update or removal, test the important user journeys and record the version that passed the checks.
A package is popular. Does that make it safe to deploy?
Popularity is one signal. You still need to consider maintenance, provenance, permissions, and whether the deployed version is affected by a relevant issue.
Sources and useful guides
The following resources provide background and more detailed guidance. Use the sections that match your service and situation.
