OWASP OASIS

What it is

OWASP OASIS is a proposed OWASP project — the page states it "has submitted a project proposal to OWASP and is currently seeking formal approval," and asks visitors to "sign up to show you are interested." So there is nothing to adopt yet; this is an interest-gathering stage for a community operating model, not a released tool or standard.

How it works

The page adds operational specifics the summary omits. The proposed implementation is a public GitHub org where only admitted members can review, update credibility scores, and advance candidates. Each candidate fix must carry a fixed data envelope: target repository, upstream base commit SHA, vulnerability category/hypothesis, generated patch or branch, reproduction notes, test evidence, and tool provenance. Validators record one of four decisions — accept, reject, modify, duplicate — with check-out / check-in timestamps and elapsed review time tracked per reviewer. The duplicate decision exists specifically to catch candidates that overlap an existing upstream PR and prevent redundant submissions.

Preconditions / Affected

The detail most likely to matter to an engineer: OASIS plans to act on repositories without their consent, at least initially. "The project may start without formal repository opt-in," and "Wait for Opt-In" is listed only as an aspiration. Preferred (pre-screened) targets are repos that are actively maintained, have recent releases/commits, working CI, documented contribution guidelines, evidence maintainers review external PRs, and security/ecosystem relevance. If you maintain such a repo, you may receive OASIS-originated security PRs unsolicited; repos that accept fixes become "preferred repeat targets" and later "explicit partner repositories."

What to do

Nothing to install or patch. If you maintain a candidate-profile OSS repo, the actionable steps are: watch for OWASP-tagged security PRs referencing a specific base-commit SHA and tool provenance, and treat them as pre-screened rather than blind mass PRs — but verify, since validation quality depends on the (not-yet-operational) credibility model. If you want to influence the model, the sign-up is the only current lever.

Caveats

• Not approved and not running. Everything is contingent on OWASP accepting the proposal.
• The page's own guiding-principles list is internally contradictory: it states the project "should not operate as a blind mass-submission engine," yet the principle table simultaneously lists "Aim for raw PR volume" (tagged Credibility) and "Minimize implementation effort" (tagged Impact). Do not assume the anti-mass-PR posture is settled — the source text does not reconcile these.
• The fetched text is truncated mid-sentence at the consensus/weighting mechanism, so how validator credibility actually aggregates into an adoption decision is unspecified here.