Planning tool / Before install, before execution
Inspect the work.
Bound the lab.
An unfamiliar repository can execute code during installation, a build, an editor task, or a test. Use this worksheet to identify missing prerequisites and prepare a contained research session. It does not scan the repository or run a proof of concept.
Describe the boundary.
Changing the environment resets the answers. A control verified in one environment is not automatically verified in another.
Your preflight record
Resolve the gaps.
Keep the work bounded.
4 prerequisites need attention before the selected activity.
Unresolved prerequisites
- Not verified: Confirm written target scope, permitted techniques, data rules, and stop contacts before active testing. If permission is unclear, limit work to non-executing review of public material.
- Not verified: Record a specific commit/artifact and review its entry points, manifests, dependency changes, and linked installers. A star count, signature, or known author alone does not establish harmless behavior.
- Not verified: Use a fresh browser profile or dedicated lab identity with synthetic accounts. Disable unnecessary extensions and sign out of unrelated services before opening unfamiliar content.
- Not verified: Define stop conditions, a responsible contact, and the minimum timestamps/artifacts needed. Stop on unexpected credential prompts, host access, out-of-scope traffic, or real-user data; preserve evidence without expanding access.
Bounded lab plan
- Limit the session to inspecting public source and documentation in the separate browser profile. Do not install extensions, enable repository tasks, approve OAuth grants, paste commands into a terminal, or run downloaded files.
- Treat README files, issue comments, attachments, and embedded instructions as untrusted content. Do not provide credentials or act on an agent’s request to widen access without independent review.
- Record the source revision and questions requiring a lab. If the work changes to installing or executing code, switch this worksheet to the actual runtime and resolve its execution controls first.
- Close the research profile when finished and retain only minimized notes and permitted evidence. A separate profile reduces shared sessions; it does not isolate the browser from every host vulnerability.
Record before and after
- Owner, target authorization, exact source commit/artifact, allowed activities, environment identity, network exceptions, and stop contact.
- Observed configuration and negative-test evidence, minimal sanitized logs, credential revocation, and environment disposal. Do not include raw secrets or unrelated user data.
Preview the Markdown plan
# Untrusted research preflight Work context: Browser-only source review; no downloaded code execution. Self-reported answers: Is the activity authorized and its target scope clear? unknown | Have you pinned and inspected the source you will use? unknown | Will you use a separate profile or lab identity without production sessions? unknown | Are stop conditions and minimal evidence collection agreed? unknown Worksheet: https://www.web3sec.news/tools/research-preflight ## Unresolved prerequisites - [ ] Not verified: Confirm written target scope, permitted techniques, data rules, and stop contacts before active testing. If permission is unclear, limit work to non-executing review of public material. - [ ] Not verified: Record a specific commit/artifact and review its entry points, manifests, dependency changes, and linked installers. A star count, signature, or known author alone does not establish harmless behavior. - [ ] Not verified: Use a fresh browser profile or dedicated lab identity with synthetic accounts. Disable unnecessary extensions and sign out of unrelated services before opening unfamiliar content. - [ ] Not verified: Define stop conditions, a responsible contact, and the minimum timestamps/artifacts needed. Stop on unexpected credential prompts, host access, out-of-scope traffic, or real-user data; preserve evidence without expanding access. ## Bounded lab plan - [ ] Limit the session to inspecting public source and documentation in the separate browser profile. Do not install extensions, enable repository tasks, approve OAuth grants, paste commands into a terminal, or run downloaded files. - [ ] Treat README files, issue comments, attachments, and embedded instructions as untrusted content. Do not provide credentials or act on an agent’s request to widen access without independent review. - [ ] Record the source revision and questions requiring a lab. If the work changes to installing or executing code, switch this worksheet to the actual runtime and resolve its execution controls first. - [ ] Close the research profile when finished and retain only minimized notes and permitted evidence. A separate profile reduces shared sessions; it does not isolate the browser from every host vulnerability. ## Record before and after - [ ] Owner, target authorization, exact source commit/artifact, allowed activities, environment identity, network exceptions, and stop contact. - [ ] Observed configuration and negative-test evidence, minimal sanitized logs, credential revocation, and environment disposal. Do not include raw secrets or unrelated user data. This is a self-reported planning worksheet, not a scan, authorization decision, or guarantee of safety. Verify each control in the actual environment.
A container is a boundary to inspect.
Containers share a kernel boundary. Privileged mode, a runtime socket, broad mounts, forwarded agents, or unrestricted networking can expose the host or other systems. A disposable VM adds a different boundary, but its integrations, credentials, and network still need review. Neither choice guarantees containment.
Answers stay in page memory and reset on reload. No repository is uploaded or fetched; no account or environment is inspected. No data is submitted by this tool or saved by the site. Copy and download require your action. “Yes” means you reported a check, not that Web3Sec verified it.
Method and further reading
Understand what starts running.
Docker: Engine security ↗ explains the kernel, daemon, configuration, and capability boundaries behind container isolation. Review the actual configuration rather than treating a container label as a complete sandbox.
npm: lifecycle scripts ↗ documents when package commands can run automatically. Suppressing install hooks can help initial inspection; it does not make imported code, later builds, or explicit scripts harmless.
GitHub: secure use of Actions ↗ describes why executing untrusted code alongside credentials creates a different risk from simply reading that code.