Ending an Open Source project does not end your responsibility to communicate clearly. If people still install, fork, teach with, or depend on your work, they need to understand the security status of what you are leaving behind.
An end-of-life security policy is a short document that answers one hard question: what should users expect if a vulnerability is found after maintenance stops? For projects that serve schools, accessibility communities, nonprofits, local governments, or other public-benefit users, this clarity matters. It helps people make safer choices even when the original project is no longer active.
Why This Stage Matters
Sunsetting a project well is part of sustainable Open Source. A quiet repository with old dependencies can still look trustworthy to a new user. A package can still be downloaded. A tutorial can still point people to your install command. Without a clear security policy, users may assume someone is watching for problems when no one is.
You do not need to promise work you cannot do. In fact, a good end-of-life security policy should avoid false reassurance. The goal is to help users understand the real state of the project, the risks of continued use, and any safer paths forward.
Step 1: Name the Project Status Clearly
Start with one plain sentence that says the project is no longer actively maintained. Avoid vague phrases like “low activity” if what you mean is “no planned fixes.”
Useful status language includes:
- Active: security reports are reviewed and fixes may be released.
- Maintenance-only: only serious bugs or security issues are considered.
- End-of-life: no fixes, releases, or security reviews are planned.
- Archived: the repository is read-only and preserved for reference.
If some versions are still supported and others are not, list them. If no versions are supported, say that directly.
Step 2: Say What You Will and Will Not Do
Users need to know whether reporting a vulnerability will lead to action. Be honest about your capacity.
Your policy can say:
- whether you will review new security reports;
- whether you will publish advisories;
- whether you will accept patches from others;
- whether you will release patched versions;
- whether you will coordinate with package registries or downstream maintainers;
- when, if ever, you will stop monitoring the project entirely.
For example, a maintainer might write: “This project reached end-of-life on September 24, 2026. I am no longer able to review or patch security reports. Please do not treat this repository as supported software.”
That sentence may feel blunt, but it protects users from guessing.
Step 3: Provide a Safe Reporting Path, or Close It Cleanly
If you can still receive security reports for a limited time, give one clear path. If you cannot, say that reports are not being monitored.
A limited reporting path might look like this:
- Report window: reports accepted until a specific date.
- Contact method: one email address or private security reporting feature.
- Expected response: best-effort review, no guaranteed fix.
- Disclosure plan: confirmed issues may be added to the project’s security notes.
If there is no reporting path, do not leave an old security email that nobody checks. A silent mailbox can create risk. Replace it with a clear note: “Security reports are no longer monitored for this project.”
Step 4: Record Known Risks in a Public Place
When a project ends, known risks should not stay buried in issue threads, chat logs, or your memory. Add a short “Known security risks” section to the README, documentation site, or security policy.
Include risks such as:
- unsupported dependencies;
- features that handle sensitive data;
- authentication or permission limitations;
- unsafe default settings;
- deployment patterns that should no longer be used;
- platform versions that are no longer tested.
You do not need to write a full audit. The point is to preserve useful warnings. If you know the project should not be used on the public internet, say so. If it is only suitable for offline demos, say so.
Step 5: Give Users Safer Next Steps
An end-of-life security policy should help users decide what to do next. For public-benefit software, many users may not have dedicated security staff. Clear guidance can reduce harm.
Offer practical options:
- migrate to a maintained alternative, if you know one;
- fork the project and take over maintenance, if the license allows it;
- remove the package from production systems;
- disable risky features;
- export data before uninstalling;
- pin the final version only for temporary internal use;
- avoid new deployments.
Be careful not to endorse a fork you have not reviewed. You can say, “Community forks may exist, but they are not reviewed or maintained by the original maintainer.”
A Concrete Example
Imagine an Open Source tool that helps teachers convert worksheets into accessible HTML for students who use screen readers. The tool was useful, free, and built with care. But the maintainer no longer has time to update dependencies or test new browser behavior.
A good end-of-life security policy might say:
- the final supported release is version 2.4;
- no future security fixes are planned;
- the tool should not be used to process private student records;
- known risks include outdated file parsing dependencies;
- users should run it only on trusted files in local environments;
- schools should migrate to a maintained accessibility workflow when possible;
- forks are welcome, but the original maintainer will not review them.
That policy does not make the old software perfect. It does something more realistic: it helps educators and technologists understand the boundary between legacy usefulness and unsafe reliance.
Step 6: Remove False Signals of Support
After publishing the policy, update the places where users may get the wrong impression.
- Add the end-of-life status near the top of the README.
- Link to the security policy from the documentation.
- Update package descriptions if you can.
- Disable badges that imply active testing if tests no longer run.
- Remove “production-ready” language if it is no longer true.
- Archive old roadmaps that suggest future releases are coming.
Small signals matter. A green badge from three years ago can make a project look healthier than it is.
Step 7: Use a Simple Policy Template
You can adapt this short structure:
- Status: This project is end-of-life as of [date].
- Supported versions: No versions are currently supported.
- Security reports: Reports are [accepted until date / not monitored].
- Fixes: No security fixes or new releases are planned.
- Known risks: [short list of important risks].
- Recommended action: Users should [migrate, remove, fork, limit use, or avoid new installs].
- Forks: Forks are allowed under the project license, but not reviewed by the original maintainer.
Put this where users will see it before they install or deploy the software.
TL;DR
An end-of-life security policy tells users the truth about an Open Source project that is no longer maintained. State the project status, list supported versions, explain whether reports are monitored, publish known risks, and recommend safer next steps. Ending a project well is not failure. It is part of building software that benefits people without leaving them to guess about their safety.