[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-76085":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":13,"subscribersCount":13,"size":13,"stars1d":13,"stars7d":13,"stars30d":13,"stars90d":13,"forks30d":13,"starsTrendScore":13,"compositeScore":13,"rankGlobal":10,"rankLanguage":10,"license":16,"archived":17,"fork":17,"defaultBranch":18,"hasWiki":19,"hasPages":19,"topics":20,"createdAt":10,"pushedAt":10,"updatedAt":21,"readmeContent":22,"aiSummary":23,"trendingCount":13,"starSnapshotCount":13,"syncStatus":24,"lastSyncTime":25,"discoverSource":26},76085,"ExecFence","chrystyan96\u002FExecFence","chrystyan96","NPM Package","https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fexecfence",null,"JavaScript",372,0,381,1,"Apache License 2.0",false,"master",true,[],"2026-06-12 02:03:39","# ExecFence\n\nGuard package-manager installs, dependency changes, CI, and agent-run commands before suspicious project code executes.\n\nExecFence is a local execution and supply-chain guardrail for JavaScript, Python, Rust, Go, JVM, .NET, PHP, Ruby, CI pipelines, package releases, and coding agents. It puts a reviewable fence in front of risky commands such as dependency installs, tests, builds, package scripts, publish steps, and agent-driven tool execution.\n\n## Quick Start\n\nRun a scan without installing globally:\n\n```sh\nnpx --yes execfence scan\n```\n\nGuard a command before it runs:\n\n```sh\nnpx --yes execfence run -- npm test\n```\n\nEnable project-local guardrails:\n\n```sh\nnpx --yes execfence guard enable\nnpx --yes execfence guard enable --apply\n```\n\nEnable global package-manager interception for terminal and agent-run commands:\n\n```sh\nnpx --yes execfence guard global-enable\n```\n\n## What Version 5 Adds\n\nExecFence v5 expands supply-chain coverage beyond npm and adds a real sandbox-helper contract in the same major release:\n\n- Windows and Linux helper support through a Go supervisor binary\n- `execfence-helper self-test` capability proof before enforce mode is allowed\n- `execfence-helper run --policy \u003Cpolicy.json> -- \u003Ccommand>` as the only enforce-mode execution path\n- helper manifests pinned by platform, arch, SHA-256, provenance, version, and self-test evidence\n- truthful strict-mode blocking when filesystem, network, process-tree, sensitive-read, or new-executable containment is unavailable\n- global shims for npm\u002Fpnpm\u002Fyarn\u002FBun, Python, Cargo, Go, Maven\u002FGradle, dotnet\u002FNuGet, Composer, and Bundler package managers\n- lifecycle-script suppression for npm-like install commands where package managers expose a reliable suppression flag\n- dependency metadata and reputation review for changed packages\n- OSV advisory checks without package-manager tokens or user credentials\n- tarball integrity\u002Fcontent audit and tarball delta against the previous version\n- `supplyChain.mode: \"strict\"` for CI\u002Frelease workflows\n- runtime dependency behavior audit with helper-backed enforcement when a verified helper proves the required capabilities\n- unified coverage evidence across `coverage`, `manifest`, `ci`, and reports: `directGuarded` means the command itself invokes ExecFence; `covered` also counts workflow-level gates, package prehooks, and active global shims\n- actionable report summaries that explain why ExecFence blocked, how the code can execute, the affected ecosystem, and the next remediation step\n- `execfence config validate` for `.execfence\u002Fconfig\u002F*` schemas, regex signatures, baselines, sandbox policy, and strict-mode coverage checks\n\nInstall-like commands such as `npm install`, `pnpm add`, `pip install`, `uv add`, `cargo add`, `go get`, `go install pkg@version`, `composer require`, and `bundle add` run through ExecFence first. When an ecosystem has a reliable lifecycle suppression flag, ExecFence delegates with scripts disabled. Ecosystems such as Go do not have a universal equivalent, so ExecFence uses preflight scan, dependency review, runtime behavior audit, and strict-mode containment checks instead of pretending scripts were disabled.\n\n## Common Commands\n\n| Command | What it does |\n| --- | --- |\n| `npx --yes execfence --help` | Prints the grouped command reference and examples. Use this to confirm the installed CLI supports the sandbox\u002Fhelper commands you expect. |\n| `npx --yes execfence scan` | Scans the current project before code runs. It blocks high-risk execution surfaces such as suspicious scripts, loaders, workflows, package hooks, and unexpected executable\u002Farchive artifacts. |\n| `npx --yes execfence run -- npm test` | Runs a command behind ExecFence. It scans first, executes only if clean, records runtime evidence, snapshots file changes, rescans changed files, and writes a report. |\n| `npx --yes execfence ci` | Runs the release\u002FCI bundle: scan, manifest diff, dependency diff\u002Freview, coverage, config validation, package audit, and trust audit. |\n| `npx --yes execfence deps review` | Reviews changed dependencies across npm\u002FBun\u002FYarn\u002Fpnpm, Python, Cargo, Go, JVM, NuGet, Composer, and Bundler manifests\u002Flockfiles with metadata, reputation, integrity, source, and runtime-surface findings. |\n| `npx --yes execfence coverage` | Shows whether sensitive entrypoints are covered by direct `execfence run`, package prehooks, workflow-level gates, or active global shims. |\n| `npx --yes execfence config validate` | Validates `.execfence\u002Fconfig\u002F*`, baselines, signatures, sandbox policy, and policy packs. It reports invalid regexes, expired baselines, unsafe allowlists, and strict-mode coverage gaps. |\n| `npx --yes execfence pack-audit` | Audits files that would be shipped in the package handoff\u002Frelease, catching dangerous scripts, unexpected binaries, archives, and suspicious publish inputs. |\n| `npx --yes execfence agent-report` | Reviews agent, MCP, tool, and instruction-file surfaces for shell\u002Ffilesystem\u002Fnetwork\u002Fbrowser\u002Fcredential access and attempts to disable security checks. |\n| `npx --yes execfence run --sandbox-mode audit -- npm test` | Runs the command normally but records sandbox policy, capability gaps, runtime trace, file snapshot, post-run scan, and report evidence. Audit mode is evidence, not containment. |\n| `npx --yes execfence run --sandbox -- npm test` | Enforce mode. It only runs if a verified Windows\u002FLinux helper proves every required capability; otherwise it blocks before the command starts. |\n| `npx --yes execfence sandbox doctor` | Prints local sandbox capability status: helper install state, `helperVerified`, capability proof, unsupported capabilities, and missing requirements for enforce mode. |\n| `npx --yes execfence sandbox plan -- npm test` | Explains the sandbox policy that would apply to a command: filesystem, process, network, helper proof, missing enforcement, and block reasons. |\n| `npx --yes execfence sandbox install-helper --binary .\u002Fpath\u002Fto\u002Fexecfence-helper` | Registers a reviewed helper binary, computes SHA-256, stores helper metadata, runs helper audit, and reports which capabilities are actually proven. |\n| `npx --yes execfence helper audit` | Rechecks the installed helper metadata, binary hash, platform\u002Farch, provenance, self-test output, capability proof, and unsupported capabilities. |\n\n## Sandbox Helper\n\nSandbox audit mode records the policy, local capability matrix, runtime trace, file snapshot, post-run scan, and report evidence. It is evidence, not containment:\n\n```sh\nnpx --yes execfence run --sandbox-mode audit -- npm test\n```\n\nThe npm package includes the helper source under `helper\u002F` so it can be reviewed and built, but it does not install a prebuilt trusted helper binary. Enforce mode stays disabled until you build or otherwise obtain a reviewed Windows\u002FLinux helper binary and register that exact file.\n\nSandbox enforce mode only runs through a verified Windows\u002FLinux helper:\n\n```sh\nnpx --yes execfence sandbox doctor\nnpx --yes execfence sandbox plan -- npm test\nnpx --yes execfence sandbox install-helper --binary .\u002Fpath\u002Fto\u002Fexecfence-helper\nnpx --yes execfence run --sandbox -- npm test\n```\n\nEnforce mode validates the helper binary SHA-256, platform, arch, provenance, and `execfence-helper self-test` output. If every required capability is proven, ExecFence writes a policy JSON and launches `execfence-helper run --policy \u003Cpolicy.json> -- \u003Ccommand>`. The helper emits JSONL events such as `spawn`, `deny`, and `exit`; deny events become blocking findings.\n\nExecFence does not count metadata-only helpers as enforcement. Unsupported capabilities are reported as `unsupportedCapabilities` and strict\u002Fenforce blocks instead of silently downgrading. The current helper proves process supervision, Windows Job Object or Linux process-group child handling, and new executable artifact detection. Filesystem pre-read denial, sensitive-read denial, and network blocking require a real platform broker\u002Felevated capability before they can be claimed.\n\n## Strict Supply-Chain Mode\n\nFor security-sensitive CI, release, or package-publishing workflows:\n\n```json\n{\n  \"supplyChain\": {\n    \"mode\": \"strict\"\n  }\n}\n```\n\n`strict` blocks unavailable metadata\u002Freputation\u002Ftarball signals, missing integrity\u002Fprovenance signals, release cooldowns, new package age windows, uncovered package-manager surfaces, invalid ExecFence config, and dependency runtime audits that lack helper-backed containment.\n\n## When ExecFence Blocks\n\nDo not rerun the command outside ExecFence just to bypass the block. Start with the report:\n\n```sh\nnpx --yes execfence reports latest\nnpx --yes execfence incident bundle --from-report .execfence\u002Freports\u002F\u003Creport>.json\n```\n\n`reports latest` prints the blocking summary first: why it blocked, how the suspicious code can execute, affected ecosystem, and the next action.\n\nIf the finding is legitimate and must be allowed, create a narrow reviewed baseline with owner, reason, expiry, and hash.\n\n## Documentation\n\nThe npm README is intentionally short. Full documentation lives here:\n\n- [Full documentation](https:\u002F\u002Fchrystyan96.github.io\u002FExecFence\u002F)\n- [Source docs](docs\u002FREADME.md)\n- [Detection model](docs\u002Fdetection.md)\n- [Release cadence](docs\u002Frelease-cadence.md)\n- [OpenAI Skills catalog PR](https:\u002F\u002Fgithub.com\u002Fopenai\u002Fskills\u002Fpull\u002F385)\n\n## Non-Claims\n\nExecFence does not replace antivirus, EDR, secret scanning, dependency vulnerability management, or human review. It does not prove that arbitrary library code is benign. It blocks and records the execution paths and supply-chain signals it can observe: scripts, lockfiles, package metadata, reputation feeds, tarballs, runtime evidence, workflows, binaries, archives, and agent\u002Ftool configuration.\n\n## License\n\nApache-2.0\n","ExecFence 是一个用于保护包管理器安装、依赖变更、CI 流程和代理运行命令的 NPM 包，防止可疑项目代码执行。其核心功能包括在执行如依赖安装、测试、构建、包脚本、发布步骤等高风险命令前设置可审查的安全屏障，并支持多种编程语言和 CI 管道。通过引入 Go 语言编写的跨平台辅助程序，ExecFence v5 扩展了对更多软件包管理器的支持，同时增强了安全性，比如文件系统、网络访问控制及新执行文件的严格模式封锁。适用于需要加强供应链安全性的开发环境，特别是在持续集成\u002F持续部署（CI\u002FCD）过程中，以及希望提高本地或全局命令行操作安全性的场景。",2,"2026-06-11 03:54:25","CREATED_QUERY"]