Most software requests sound harmless. Someone needs a browser extension. A development team wants a package that saves a week of work. Sales needs a SaaS platform before the end of the quarter. The business question is usually, "What does it cost?" The security evidence arrives later, if it arrives at all.
That order is backwards. Once the software is in place, the business has less room to negotiate and starts accumulating switching costs. The useful time to learn that an extension can read every page, or that a vendor cannot explain its privileged access controls, is before either becomes part of normal operations.
The question we should be asking is: what would it cost if we implement this and it gets breached? NIST IR 8286D explains how business impact analysis can inform risk prioritization, while NIST IR 8286 Rev. 1 places cybersecurity risk inside enterprise risk management rather than treating it as a separate technical score.
Why I say source-readable, not open source
Open source is a licensing category. It describes rights a qualifying license grants to use, modify, and redistribute software. Source-readable describes an evidence condition: a reviewer can obtain and read the code that will run.
The distinction matters. A browser extension may publish its source or ship readable JavaScript without granting an open-source license. A commercial package may provide source under a restrictive agreement. You may be able to evaluate the source code even when you do not have the legal rights normally associated with open source. The reverse is also possible: a project can have an open-source license, while the artifact you were given cannot be tied confidently to the published repository.
Licensing answers what you may do with the code. Source readability answers what you may be able to learn from it. Neither proves that the artifact is safe.
Businesses need both answers. A copyleft license may permit modification and distribution only if specific conditions are met, such as licensing covered derivative work under the same terms and providing the corresponding source. The GNU GPL version 3 states those conditions directly. Using or distributing code outside the license can create copyright claims, lawsuits, an injunction that stops distribution, and monetary damages. This is a reason to involve qualified counsel when the terms or planned use are unclear. It is not legal advice.
Two evidence paths, two different questions
When the software is source-readable
You can examine behavior directly. That includes authentication and authorization logic, data collection and transmission, dangerous permissions, injection paths, cryptography, error handling, configuration defaults, dependencies, build hooks, and code quality signals that affect maintainability. You can also compare a published package or extension against the claimed source when the release process permits it. The NIST Secure Software Development Framework provides a useful vocabulary for examining development practices and protecting software from tampering.
Direct code evidence still has limits. A review can miss context, runtime behavior, infrastructure controls, generated code, or a malicious update delivered tomorrow. Readable code improves the quality of the questions. It does not eliminate the need for judgment or ongoing control.
When the software is operated by a commercial vendor
You normally cannot inspect the production service. Instead, you evaluate the organization through its SOC 2 report, penetration-test summary, security questionnaire, architecture and data-flow documentation, privacy terms, trust center, incident history, and answers to follow-up questions. That evidence-based approach follows the due-diligence questions in NIST SP 1326 and the broader supply-chain risk practices in NIST SP 800-161 Rev. 1.
Those documents can show that controls exist and were tested. They can also expose scope limitations, exceptions, vague commitments, and places where the vendor's evidence does not support the sales claim. They cannot decide whether the vendor is appropriate for your specific use.
A practical manual workflow
- Define the proposed use. Record the business owner, purpose, users, data types, integrations, privileges, deployment location, internet exposure, and what would stop working if the software disappeared.
- Identify the evidence path. Collect the actual source and release artifact for source-readable software. For a vendor, collect current audit reports, testing evidence, questionnaires, policies, diagrams, and contractual commitments.
- Test provenance and scope. Confirm that the code, package, report, or service being reviewed is the one being proposed. A clean repository does not help if the distributed artifact comes from somewhere else. A SOC 2 report does not help if your service or relevant environment is excluded.
- Evaluate material controls and failure modes. Review access control, data protection, injection risk, cryptography, error handling, deployment configuration, dependencies, third-party components, operational controls, resilience, and incident response as applicable.
- Separate proof from assertion. Mark each important requirement as supported, unsupported, partially supported, or pending. Capture the citation or code reference that justifies the status.
- Document uncertainty. Missing evidence is not a passing control. It may be acceptable, but acceptance should be explicit and owned by someone with authority.
- Make a bounded decision. Approve, conditionally approve, hold pending evidence, or deny. Conditions should have an owner and a deadline.
Business context changes the answer
The same software can be reasonable in one use and reckless in another. A browser extension used on a kiosk with no sensitive data is not the same risk as the same extension used by payroll administrators. A SaaS vendor storing public marketing assets is not equivalent to one receiving health records or domain-administrator access.
Technical review should therefore be joined with data sensitivity, exposure, user population, business criticality, contractual obligations, compensating controls, risk appetite, decision ownership, and a reassessment trigger. These facts are not defects in the software. They are the context that turns evidence into a decision.
A worked decision: the useful browser extension
Suppose the finance team requests an extension that cleans up data copied from a web-based accounting platform. The store page is polished, the ratings are good, and the extension costs less than one employee hour each month. If the review stops at purchase price, approval is nearly automatic.
The source tells a more useful story. The manifest requests access to every website, not only the accounting platform. The code reads page content and sends telemetry to a vendor endpoint. Neither fact proves malicious intent. Broad host access may be the simplest implementation, and telemetry may support a legitimate feature. The review question is whether those capabilities are necessary for this deployment and whether the vendor's explanation is supported by the code and privacy terms.
Now add business context. Finance users open banking portals, payroll records, tax documents, and administrator sessions in the same browser. A compromise or careless update could expose much more than the extension's advertised data-cleaning workflow. The purchase price did not change. The potential consequence did.
A reasonable decision might be conditional approval: restrict the extension to its required host through managed browser policy, prohibit its use in administrative profiles, disable optional telemetry if the product supports that configuration, and reassess every material version change. If the extension cannot function under those limits, the business can compare alternatives before training, process dependence, and accumulated data make replacement expensive. That is what review before implementation buys you. It does not buy certainty. It preserves choices.
The strongest argument against reviewing everything
A full assessment of every tool is expensive and often disproportionate. The answer is not to pretend every request deserves identical scrutiny. It is to triage consistently.
Low-privilege tools handling public data may receive a lightweight review. Software with broad browser permissions, sensitive data, production access, code execution, identity integration, or operational dependency deserves more. The important control is a documented threshold, not a ritual that treats a calculator and an identity provider as peers.
Carry the evidence into the approval record
Use the browser-extension workbook for permissions and browser context, or the source-readable software workbook for packages, applications, repositories, and other inspectable artifacts. Both cover scope, evidence, criteria, follow-up, decision, and reassessment.
Sources and further reading
- NIST SP 1326, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment Quick-Start Guide
- NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
- NIST SP 800-218, Secure Software Development Framework
- NIST IR 8286 Rev. 1, Integrating Cybersecurity and Enterprise Risk Management
- NIST IR 8286D, Using Business Impact Analysis to Inform Risk Prioritization and Response
- Open Source Initiative, The Open Source Definition
- GNU General Public License, version 3
- 17 U.S.C. Section 502, Remedies for infringement: Injunctions
- 17 U.S.C. Section 504, Remedies for infringement: Damages and profits
Managing repeated reviews
Can I Run That? can organize source analysis, vendor evidence, citations, follow-ups, and decision history across many reviews. Accountable reviewers still supply business context, validate findings, and own the decision.
The standard is not certainty
No review proves that software is safe. The practical standard is a decision made from the best available evidence, with important gaps and assumptions visible. Review before implementation because that is when you still have room to negotiate and a clean exit.