Skip to main content

Publishing to the Community Library

Feature row 39 — Sprint CPL-2

Publishing is available to any tenant. Artifacts pass through a validation gate before they're visible in the public browse list.

Who should publish​

If you've written a policy, DLP pattern, or inbound rule that catches a real threat and is general enough to be useful outside your tenant, consider publishing it. Good candidates:

  • Policy templates for common scenarios other teams will face (e.g. "block SSH key exfiltration from any shell tool")
  • DLP patterns for data formats that aren't in the default set (country-specific IDs, industry-specific identifiers)
  • Attack fingerprints derived from real incidents or ARS findings
  • Compliance packs that bundle the above for a specific vertical or framework

Not good candidates: anything tenant-specific (hardcoded IDs, internal domains), anything that depends on custom tooling the community doesn't have, anything under NDA.

The 4-step wizard​

Library → Community → Publish.

Step 1 — Pick the source​

Three sources:

  • Existing artifact in your tenant — pick a policy, DLP pattern, or inbound rule you already use
  • Fresh authoring — write the artifact directly in the wizard
  • Compose a pack — combine existing artifacts into a named bundle

The wizard fetches the source, shows a read-only preview in CodeMirror, and asks you to confirm before moving on.

Step 2 — Metadata​

  • Name (unique across the community namespace)
  • Description — a few paragraphs explaining what it does and when to use it
  • Tags — free-form plus a curated taxonomy (framework, vertical, attack class)
  • License — MIT, Apache 2.0, or custom text
  • Maintainer contact — email or GitHub handle; required for updates and questions
  • Link to incident / write-up — optional but strongly encouraged

Step 3 — Validation gate​

The contribution service (backend/behavry/community/service.py) runs the artifact through an automated gate. All stages must pass before submission.

StageRuns onPurpose
OPA compilePoliciesMust compile cleanly with the pinned OPA version
Rego lintPoliciesNo default missing, no unreachable rules, no unused imports
Pattern validateDLP patternsRegex compiles; entropy thresholds are sane; no catastrophic backtracking
Test corpusDLP patternsMust match the contributor-supplied positive set and skip the negative set
Schema validateInbound rulesMatcher config matches the declared type; action is terminating where required
Pack validatePacksAll member artifacts resolve; no circular references; versions pinned
Tenant-data scanAllAutomated scan for tenant-specific strings (IDs, domains, emails). Any hit blocks submission with a diff.

Failures are shown inline with the specific rule / line. You can fix and retry without losing the rest of your submission.

Step 4 — Submit​

On submit, the artifact lands in a review queue. Curators (Behavry team + opt-in community reviewers) check for:

  • Does the description match the artifact?
  • Is the license clear?
  • Is it actually useful outside the contributor's tenant?
  • Are tags accurate?

Approved artifacts become visible in the browse list immediately. Rejected artifacts include feedback the contributor can act on; you can revise and resubmit.

Updating​

Once published, you own the artifact. Push new versions from:

  • Library → Community → My Contributions → (artifact) → New version, OR
  • POST /api/v1/community/artifacts/{id}/versions

Every new version re-runs the validation gate. Subscribers are updated on their next sync cycle; installers see a notification but nothing changes until they act.

Ownership & transfer​

Maintainers can:

  • Transfer ownership to another maintainer (email-verified)
  • Deprecate the artifact (stays readable but shows a deprecation banner)
  • Unpublish — removes from browse but not from existing installs

Deletion of the underlying bytes is not exposed: once content is in the log, it stays.