One maintainer, one contract, and a public record of what is unproven.

What SecHelix is

SecHelix is an open-source application-security Agent Skill and evidence-first security workflow created by Omar Mohamed Helal. It is licensed Apache-2.0, developed in the open at github.com/omarmohelal/SecHelix, and this site — sechelix.com — is its official home.

It is a set of files a coding agent loads: a methodology, a structured catalog of security hypotheses, role profiles, JSON contracts, and validation scripts. It is not a binary, a hosted service, a scanner, or a company, and it is unrelated to any similarly named commercial product. It runs against repositories and environments you own or are explicitly authorized to test. See what an AppSec agent is for the category, and the benchmark page for what has and has not been measured.

The mission is narrow and it is the whole project: make a security finding cost something to assert. A scanner alert, a model suspicion, and a confident paragraph are all claims. SecHelix keeps them labelled as claims until an evidence chain establishes attacker control, reachability, a failed trust boundary, a safe reproduction, concrete impact, a root cause, a fix, and a regression proof — and it requires an independent pass that tries to refute High and Critical candidates before they are reported.

The methodology in brief

One lifecycle runs for every task shape, whether the target is a whole repository or a single pull request. The phases are not advisory; each one has an output contract that the next phase reads.

1. MapBuild entrypoints, identities, stores, trust boundaries, state machines, and a role-by-object-by-action matrix from evidence rather than assumption.
2. SelectLabel every catalog hypothesis APPLICABLE, NOT_APPLICABLE, UNKNOWN, or BLOCKED before any testing. Missing evidence is never read as absence.
3. HuntSpecialist lanes trace attacker control, reachability, failed boundaries, second-order paths, and business invariants in parallel.
4. VerifyA neutral pass receives the candidate as a claim to disprove, without the hunter narrative or the desired verdict. Agreement between models is not verification.
5. FixRepair the canonical invariant rather than the symptom, then search sibling paths for the same defect.
6. ProveWrite the test against the vulnerable build first and watch it fail for the security reason, then apply the repair.
7. GateReturn PASS, PASS_WITH_KNOWN_RISK, BLOCKED, or INCOMPLETE. Missing or malformed evidence fails closed.

The full contract lives in the public repository: references/methodology.md, the five-minute path in docs/QUICKSTART.md, and the machine-checkable side in the versioned JSON schemas. The site documentation covers the same ground in more depth.

Who builds it

One person. SecHelix is maintained by Omar Mohamed Helal Emam (@omarmohelal), as recorded in CITATION.cff. There is no company behind it, no team, no funding round, and no commercial entity that owns the methodology.

• There is one maintainer and no review SLA. Security reports are prioritised over everything else.
• Community extensions enter through a curated registry as COMMUNITY. Contributors cannot self-assign INCUBATING or OFFICIAL — that is a separate maintainer decision after safety review and fixture proof.
• The project has no customers, no adoption numbers to report, and no reference logos. Those sections are absent from this site rather than filled with plausible placeholders.

Developed with AI, directed by a human

SecHelix is developed with substantial AI assistance. A human maintainer sets the direction, decides what ships, and is accountable for every claim the project makes. A large share of the drafting — methodology prose, catalog records, schemas, adapters, tests, the evaluation fixtures, and this website — was produced by AI coding sessions working under that direction and then reviewed.

This is stated here rather than buried, because a project whose entire argument is that findings must be proved cannot reasonably ask readers to take its own provenance on trust. If the disclosure changes how you weigh the rest of the site, that is a correct response to it.

• Every factual claim on this site is meant to trace to a file in the public framework repository. Where it does not, that is a defect worth reporting.
• Inventory counts — hypotheses, families, lenses, fixtures, adapters — describe what exists in the tree. They are not measurements of how well any of it performs.
• No accuracy, recall, precision, or false-positive number is published anywhere on this site, because none has been measured under conditions that would make it meaningful.

The licence

The framework is licensed under Apache-2.0. That choice is deliberate: a permissive licence with an explicit patent grant removes the usual legal friction for a company that wants to run a security methodology on its own code.

What it grants

Use, modification, and distribution, including commercial use, plus an express grant of the contributors’ relevant patent rights.

What it requires

Keep the licence text and the existing copyright, patent, trademark, and attribution notices, and state significant changes you make.

What it does not grant

Trademark rights in the SecHelix name or marks, and no warranty or liability of any kind. The software is provided as is.

What it covers

The public framework repository — the skill, catalog, schemas, adapters, scripts, policies, and documentation. This marketing website is a separate, private repository and is not part of that grant.

The full text is in the repository: LICENSE.

Responsible use — the boundary

The boundary is enforced structurally rather than by a warning banner. Authorization and execution mode are recorded in the scope record before any testing runs, and a run that cannot establish them returns BLOCKED instead of proceeding on an assumption.

STATIC

Code reading and static evidence only. No traffic is generated against a running system.

LOCAL

Runtime reproduction against a local fixture or a local build you control.

STAGING

An explicitly authorized non-production environment, with allowlisted targets.

PRODUCTION_SAFE

A bounded mode for explicitly authorized systems, using non-destructive evidence only. Anything that could mutate money, identity, inventory, customer data, external-provider state, or availability belongs in a local or staging fixture unless separately approved.

• If you find a vulnerability in a third party's system while using SecHelix, complete responsible disclosure with that party first. This project is not a disclosure intermediary.
• If you find a vulnerability in SecHelix itself, report it privately — SECURITY.md explains how, and /contact summarises it. Do not open a public issue for an unpatched vulnerability.
• Evidence contains things you do not want indexed. Never paste credentials, private source, customer data, or internal hostnames into a public thread; use the redacted report output.

What this project does not claim

This table is the short version of the limitations recorded in the repository README. It is here because a trust page that only lists strengths is not a trust page.