Skip to content

Secfoo Hackathon: start here #58

Open

Description

@vsn411

Welcome! This issue lists everything open for the hackathon.

Setup: follow CONTRIBUTING.md: pip install -e ".[dev]", then pytest tests and ruff check ..

Claiming an issue: comment "I'd like to take this" on the issue and a maintainer will assign you. One issue per person at a time, please. If there's no PR within 5 days, the issue goes back in the pool.

Core CLI

Custom skills

Runtime sensor for SCA (tracking issue: #51)

An opt-in sensor, deployed explicitly (e.g. as a sidecar) with the same Secfoo API key used for scans, that runs alongside a threat-modeled or assessed app, in any runtime and on any platform, and confirms whether vulnerable dependencies are loaded, executed and reached by live traffic. Read #51 first for the design rules. Agree on the formats in #52, #53 and #73 before building on them.

Phase 1: offline evidence

Phase 2: live sensor

Phase 3: more runtimes (each needs #73)

Questions: ask in the issue thread.

Activity

  1. added
    hackathonOpen for the Secfoo hackathon
    trackingUmbrella or announcement issue; not a task, not scored
    on Nov 8, 2026
  2. added
    needs difficultyMaintainer: add difficulty: hard, medium or low so this can be scored
    on Nov 11, 2026
  3. vsn411 commented on Nov 11, 2026

    @vsn411
    CollaboratorAuthor

    A note on PRs, after reviewing the first few.

    For a PR to be merged it needs to:

    1. Target one sub-issue. Put Fixes #<n> for that issue in the description. Tracking issues (Tracking: Runtime reachability for SCA (in-app probe + live sensor) #51, this one) are not tasks; a PR that says Fixes #51 will be closed.
    2. Include tests. Every issue has a "done when" line; the tests should cover it. PRs without tests won't be reviewed for code.
    3. Pass CI. pytest tests and ruff check . locally first. First-time contributors need a maintainer to approve the CI run, so a green local run saves a round trip.
    4. Build to the agreed formats. For the runtime sensor work, Build a vulnerable-function watchlist from advisories #52 (watchlist), Runtime evidence format, storage and secfoo runtime ingest #53 (events) and Probe ↔ sensor protocol and conformance kit (one contract for every runtime) #73 (probe protocol) are the contracts. Don't invent a different shape; if you think one should change, say so in that issue first.
    5. Go through the real code paths. New commands are registered in src/secfoo/cli.py. New code gets its own module. Nothing goes in src/secfoo/__init__.py, and nothing patches the standard library or other libraries at import time.
    6. Be reviewable. Descriptive names, one statement per line, the style of the surrounding code. If you used an AI agent to draft it, that's fine; read and test the result yourself before opening the PR.

    Points. Merged PRs score on the contributor leaderboard based on the difficulty: label of the issue they close: hard 10, medium 6, low 3. Bronze at 25, Silver at 50, Gold at 100. Every open issue above now carries a difficulty label. Details in CONTRIBUTING.md.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    hackathonOpen for the Secfoo hackathonneeds difficultyMaintainer: add difficulty: hard, medium or low so this can be scoredtrackingUmbrella or announcement issue; not a task, not scored

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions