What npx sekura init actually does

Running a command from npm is an act of trust. Here is exactly what that trust buys you.

Before your shell prompt returns

The npx runtime downloads sekura@latest from the npm registry over TLS 1.3. That is table stakes for any package. What comes next is not.

We ship a detached ed25519 signature alongside the package tarball. The installer checks it before executing a single line of application code. The public key is pinned in the binary. There is no network call to fetch it. If the signature check fails, the installer exits with a non-zero code and prints the expected versus received fingerprint so you can audit it yourself.

$ npx sekura@latest init

Fetching [email protected] from registry.npmjs.org...
Verifying package signature... ok (ed25519/sha-256)
Detecting IDE environment...

I think this step matters more than it sounds. Supply-chain attacks target exactly this moment. A compromised package that skips its own verification is invisible to your terminal.

IDE detection and MCP registration

The installer scans for active development environments in a fixed order. It checks running processes, config directories, and environment variables set by each IDE's native extension host.

The detection order is:

1. Claude Code: checks for CLAUDE_CODE_ENTRYPOINT in the environment and ~/.claude/ on disk.
2. Cursor: looks for cursor in the running process list and ~/.cursor/extensions/.
3. VS Code: checks VSCODE_PID and ~/.vscode/extensions/.
4. Windsurf: checks for windsurf in the process list and ~/.windsurf/.

If multiple IDEs are detected, you are prompted to pick one. If none are detected, the installer writes a generic MCP config to ~/.config/sekura/mcp.json and prints the path.

The MCP server registration tells your IDE where to route Sekura tool calls. After init completes, your IDE can ask Sekura to describe a finding, show a proof-of-exploit, or re-run a specific scan phase without leaving the editor.

OAuth and keychain storage

Init opens a browser tab to https://app.sekura.ai/oauth/authorize. You authenticate with GitHub. We issue a short-lived JWT and a longer-lived refresh token.

The tokens are stored in your system keychain, not in a dotfile.

macOS:   Keychain Access (service name: "sekura-ai")
Linux:   libsecret / GNOME Keyring or KWallet
Windows: Windows Credential Manager

We never write tokens to disk in plaintext. The keychain API handles decryption in memory. If you revoke access from app.sekura.ai/settings/tokens, the refresh token is invalidated server-side and the next credential read returns an authentication error locally.

The installer does not ask for your GitHub token. It asks GitHub to authenticate you via OAuth, and GitHub tells us who you are. We never see your GitHub credentials.

Workflow commit and scan dispatch

The last step wires up continuous scanning. Init commits a GitHub Actions workflow file to your repository and sets one repository secret.

The committed workflow file is short. Two jobs: one that runs on every pull request, one that runs on pushes to main.

name: Sekura Security Scan

on:
  pull_request:
  push:
    branches: [main]

jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: sekura/scan-action@v1
        with:
          token: ${{ secrets.SEKURA_TOKEN }}

The fetch-depth: 0 is not boilerplate. We need the full commit history for white-box SAST. A shallow clone produces false negatives because our SAST phase traces data flows across commit boundaries.

The scan action dispatches to the Sekura platform. From there, the seven-phase pipeline runs: white-box SAST, recon, dynamic probing, exploit synthesis, exploit-chain analysis, post-quantum cryptography review, and reporting. Each phase runs as a specialized agent. Results arrive as SARIF uploaded to GitHub's code scanning UI, and as inline review comments on the pull request with working proofs-of-exploit attached.

After init

Most security tools require ongoing configuration. New environment variable here. Updated YAML key there. Another credential rotation next quarter.

I believe the better path is a single setup step that handles its own maintenance. Init stores credentials in the keychain so they survive reboots. The workflow file pins the action to a major version so you get patches without thinking about them. The MCP registration stays current because the server version is negotiated at connection time, not hardcoded.

Security tooling that requires constant attention does not get that attention. The teams that ship secure software are the ones who made security automatic, not the ones who made it thorough.

See the full scan pipeline at /product/.