“Anyone can inspect the code” is true of open-source software. It does not establish that anyone has inspected the version you are about to deploy.
Nor does it tell you whether your administrator left the database exposed. The licence cannot rescue that decision.
The short answer: assess the exact release and your deployment together. Check provenance, dependencies, access, configuration, patching and recovery, then assign an owner. Security is an operating responsibility, not a property you inherit from a repository badge.
Identify exactly what you are deploying
Record the project, release, source location, package or image digest and licence. Obtain the artefact from the project’s documented distribution route. Check available signatures or attestations according to the project’s instructions.
Include plugins, extensions, container base images and dependencies. A clean core application can still arrive with vulnerable or abandoned components. Keep an inventory that can be matched against later advisories.
The OpenSSF Scorecard helps inspect repository practices. Read its individual checks and context. A score is a signal for investigation, not permission to deploy.
Use a deployment checklist
| Check | Practical evidence | Typical action if missing |
|---|---|---|
| Provenance | Documented source and pinned artefact | Stop and establish origin |
| Vulnerabilities | Scan plus review of relevant findings | Patch, mitigate or reject |
| Permissions | Tests with ordinary and privileged accounts | Reduce access and retest |
| Secrets | Approved storage and rotation route | Remove embedded credentials |
| Exposure | Documented public and private interfaces | Close unnecessary access |
| Recovery | Restore completed from a real backup | Fix recovery before relying on it |
| Updates | Supported release and upgrade rehearsal | Establish a maintainable path |
| Ownership | Named responder and escalation route | Assign responsibility |
Triage findings rather than counting them
A scanner’s total is not a risk decision. Ask whether the affected component is present, whether the vulnerable functionality is reachable, what an attacker would need and what the consequence would be. Record the evidence and the person accepting any residual risk.
Do not dismiss a serious issue because it is inconvenient to patch. Equally, avoid declaring a system unsafe solely because a scanner reports an irrelevant dependency without examining how it is used.
The CISA Known Exploited Vulnerabilities catalogue can help prioritise vulnerabilities known to be exploited. Absence from the catalogue does not establish safety.
Test the configuration your users will receive
Create accounts with different roles and attempt actions they should not be able to perform. Check direct object access, exports, administrative functions and service accounts. Inspect defaults rather than assuming they are suitable for your environment.
Review logging for both usefulness and leakage. Operators need enough evidence to investigate a failure, but logs should not casually accumulate credentials or sensitive records. Agree retention and access with the relevant owners.
For an AI-enabled application, add tests for untrusted instructions, excessive tool permissions and retrieval across access boundaries. Those risks sit on top of the application’s ordinary security responsibilities.
Rehearse maintenance and recovery
Apply an update in a representative environment, run the critical workflow checks and rehearse rollback or restoration. Confirm what happens to data created after the backup. An image of yesterday’s application is not necessarily a recoverable service.
Time the restore and compare it with the service expectation. If the business can tolerate only a short interruption and recovery takes most of a day, make the mismatch visible before launch.
Keep the runbook with the people who will respond. A supplier’s private knowledge is a continuity risk even if that supplier is very good at their job.
Decide who can release it
List release-blocking findings, accepted exceptions, expiry dates and the accountable approver. Reassess after significant upgrades, architectural changes or newly relevant advisories.
A checklist is useful when a failed check changes the decision. If every row can be marked “to follow” and the launch continues regardless, you have created a record of optimism.
Sources and scope
Reviewed 1 November 2026. The examples and worksheets are my suggested working methods, not measured client results or official standards.
