This checklist applies to public repositories, browser extensions, packages, and authorized source archives. Source-readable does not promise a license that satisfies the Open Source Definition. It means the reviewer can inspect the code. Confirm licensing separately, including any copyleft and corresponding-source conditions stated in licenses such as the GNU GPL version 3.
Build the review record
Source-readable software approval workbook
Identify the exact source and artifact, scope deployment and privileges, inventory evidence, and assess vulnerabilities, dependencies, authentication and authorization, data protection, injection attacks, cryptography, error handling, configuration and deployment, code quality, third-party components, provenance, malware indicators, licensing, testing, and ownership. Then document follow-ups and the decision.
- Understand the boundary. Read why source-readable does not necessarily mean open source.
- Run the technical review. Use the security review methodology to connect evidence, findings, business context, and the final decision.
- Go deeper for packages. Use the NPM package guide for lifecycle scripts, tarballs, provenance, and transitive dependencies.
- Record limitations. State what was not covered, whether the distributed artifact matched the source, and where qualified human review is still required.
Write findings that can be checked
Each material finding should include severity, category, description, impact, code reference, evidence, uncertainty, and potential mitigating controls. Separate facts from interpretation. A score without the path back to evidence is decoration.
Approval still needs business context
Record the owner, use, systems, data flow, users, sensitivity, exposure, privileges, criticality, compensating controls, risk appetite, contractual restrictions, decision authority, and reassessment plan. Code risk becomes organizational risk only through deployment.
State what the review could not establish
Note generated or missing code, unsupported languages, unavailable package intelligence, runtime infrastructure, external services, test limitations, partial inventory, and whether the distributed artifact matched the source. Readable code is a strong flashlight, not daylight everywhere.
Make the approval decision
Summarize overall grade or risk, top concerns, evidence coverage, licensing, mitigating controls, and the final approve, conditional, pending, or deny decision. Attach configuration requirements, owners, deadlines, allowed version, and review triggers.
Sources and further reading
Managing repeated source reviews
Can I Run That? can organize source analysis, dependency and package evidence, citations, coverage records, and reassessment across many reviews. A human reviewer still validates material findings, supplies business context, and owns the decision.