Status: alpha threat model · Updated: 2026-07-13

Modulora is a package registry, identity system, external commercial listing directory, and software supply chain. Security is a product requirement, not a badge added after launch. This document defines the minimum posture for creator accounts, component releases, installation, external commercial listings, and platform operations.

Direct marketplace custody isn't active during alpha. Modulora doesn't process component purchases, hold paid source, grant buyer entitlements, or manage refunds and disputes for external sales. Marketplace threat-model sections are future gates, not claims about a live alpha capability.

1. Only authorized creators can publish or change a component listing.
2. Users can determine exactly what identity and evidence apply to an immutable release.
3. A compromised creator, dependency, worker, or integration cannot silently compromise the platform.
4. Registry payloads cannot write outside approved project boundaries or execute arbitrary install behavior.
5. Untrusted code cannot reach production data, credentials, control-plane services, or internal networks.
6. Compromise can be detected, contained, revoked, investigated, and communicated.
7. External commercial listings never receive claims Modulora cannot substantiate.

• Creator and organization ownership.
• Publishing authority and release history.
• Better Auth sessions, passkeys, MFA factors, recovery methods.
• GitHub App private keys and installation tokens.
• Artifact signing keys and revocation state.
• Production database, object storage, queues, and cloud credentials.
• Private component source when hosted delivery is introduced.

• Component names and namespaces.
• Provenance attestations and security evidence.
• Audit logs and moderation records.
• Purchase links, promotion campaigns, billing and payout data.
• Search ranking and install analytics.

Untrusted internet
  ├─ browser content, uploads, metadata, URLs, reports
  ├─ registry files and dependency manifests
  └─ GitHub webhook events
          |
Edge boundary: TLS, WAF/rate limits, request validation
          |
Control plane: identity, catalog, publishing, authorization
          |
Queue boundary: signed job descriptions, no credentials in payloads
          |
Worker boundary: ephemeral isolated execution, no control-plane network
          |
Artifact boundary: immutable storage, digest/signature verification
          |
Client boundary: CLI verifies before atomic local writes

Better Auth is the authentication foundation, not the authorization policy by itself.

• Passkey or phishing-resistant MFA for every publisher and platform administrator.
• Verified email; verified domain for organization identity claims.
• Secure, HttpOnly, SameSite cookies and session rotation after authentication and privilege changes.
• Session/device inventory with individual and global revocation.
• Step-up authentication for publish, ownership transfer, namespace transfer, visibility changes, recovery changes, billing, API-key creation, and destructive actions.
• Login, recovery, ownership-transfer, and new-publisher notifications.
• Rate limits and abuse detection on login, recovery, invitation, and token endpoints.
• OAuth account linking requires an authenticated session and reauthentication; matching email alone is insufficient.

Recovery is a common account-takeover path:

• Recovery codes are one-time, hashed at rest, and regenerated only after step-up authentication.
• Sensitive recovery changes trigger a cooldown before publishing or ownership transfer.
• Existing sessions and factors are notified; high-risk changes can revoke other sessions.
• Organization ownership recovery requires dual evidence and human review; support cannot instantly bypass it.
• Administrators use separate privileged accounts and hardware-backed MFA.

Roles are explicit and resource-scoped:

Every request rechecks membership, role, resource ownership, and organization state server-side. UI visibility is never authorization.

Use a GitHub App, not broad personal access tokens.

• Request only repository metadata and content permissions needed for selected repositories.
• Installation tokens are short-lived, generated server-side, and never sent to the browser or worker.
• Verify webhook signatures using the raw request body; enforce timestamp/replay controls and idempotency.
• Reconcile installation/repository permissions periodically rather than trusting webhook delivery alone.
• Detect repository transfer, deletion, default-branch change, revoked installation, and namespace ownership changes.
• Publishing requires explicit authorization against an immutable commit; a webhook alone cannot publish.
• GitHub App private keys live in a managed secrets/KMS system, rotate regularly, and have a compromise runbook.

All creator-controlled inputs are untrusted:

• Parse strict JSON with depth, size, item-count, and string-length limits.
• Reject unknown high-impact fields in strict mode.
• Normalize Unicode names and detect confusable/typosquatted namespaces.
• Reject absolute paths, .., null bytes, device paths, symlink/hardlink escapes, and case-collision attacks.
• Restrict allowed shadcn item types and destination roots.
• Reject arbitrary shell commands and package lifecycle scripts.
• Treat envVars as named placeholders only; scan values and files for secrets.
• Sanitize Markdown/HTML; prohibit active SVG and proxy untrusted images.

A published version is immutable and includes:

• normalized shadcn manifest;
• Modulora companion manifest;
• file-level SHA-256 or stronger digests;
• exact source repository and commit;
• dependency and registry-dependency set;
• evidence records and policy versions;
• canonical release digest;
• publisher authorization and platform attestation.

Changing any field produces a new version. Deprecation and revocation append state rather than rewriting history.

• Define canonical serialization before implementing signatures.
• Platform signing keys live in KMS/HSM-backed custody and are never available to web or worker processes.
• Record key identifier, algorithm, signature time, and transparency-log reference.
• Support rotation, revocation, compromised-key cutoff times, and client trust-store updates.
• The CLI fails closed for invalid, unknown, revoked, or mismatched signatures.
• Hashes prove integrity; signatures connect integrity to an identity. Never conflate them.

Never use one generic “secure” or “verified” label. Show independent evidence:

Evidence pages include digest, version, timestamps, scanner versions, limitations, and superseding/revoked state.

External commercial listings must display Source not assessed by Modulora unless the creator grants review access under a defined program.

No arbitrary component execution ships before an independent sandbox review.

• Ephemeral single-job isolation using hardened microVMs or equivalent—not process-only containers.
• Dedicated cloud account/project and network separate from the control plane.
• No production credentials, instance metadata access, host sockets, or shared writable volumes.
• Unprivileged user, read-only base image, ephemeral filesystem, syscall/capability restrictions.
• CPU, memory, process, disk, output, and wall-clock limits.
• Network denied by default. Dependency access only through a controlled, logged proxy/cache with policy enforcement.
• Job input and output transferred through narrowly scoped object-storage grants.
• Worker images are pinned, signed, scanned, patched, and rapidly revocable.
• Sandbox escape detection, kill switch, forensic logging, and incident response.

• Previews run on a separate origin with no shared cookies.
• Sandboxed iframes use the minimum capabilities.
• Strict CSP, no top navigation, no opener access, no arbitrary downloads.
• External network access is blocked or explicitly declared and proxied.
• Screenshots are preferred for untrusted or external commercial components until live-preview safety is established.

The CLI is a security boundary and must be independently threat-modeled.

1. Resolve an exact immutable version.
2. Fetch the manifest, attestation, and evidence over TLS.
3. Verify signature, digest, revocation, and namespace.
4. Produce a dry-run plan listing every file and dependency/config change.
5. Enforce safe roots and reject traversal, symlink, case-collision, and overwrite attacks.
6. Require explicit approval for dependency installation and high-impact config files.
7. Stage changes in a temporary directory.
8. Apply atomically, save a rollback record, and write modulora.lock.
9. Never execute creator-supplied commands or install hooks.
10. Never embed long-lived tokens in commands, logs, shell history, or query strings.

• Publish from protected GitHub environments using npm trusted publishing/OIDC and provenance where available.
• No long-lived npm publish token.
• Mandatory review and signed/protected release tags.
• Reproducible build target and public checksums.
• Malicious-registry fixtures, fuzz/property tests, and path/symlink tests block release.

Launch behavior deliberately avoids paid-source custody.

• Verify the creator controls the destination domain.
• Display the final destination domain before navigation.
• Prevent open redirects and continuously monitor redirects/domain ownership changes.
• Scan links for malware/phishing signals and provide reporting/takedown.
• Mark price and commercial terms as creator-provided with a last-checked timestamp.
• Do not display install commands that imply Modulora delivery.
• Do not claim the unseen source was scanned, reviewed, or signed by Modulora.
• Creator-hosted demos remain untrusted and open in an isolated/new context.

Hosted commercial delivery later requires a separate review covering encryption, entitlement tokens, payment security, seller identity/tax, refunds, leakage, abuse, and the reality that source code cannot be durable DRM after installation.

• Protected namespace list and similarity/confusable detection.
• Verified organization/domain indicators based on evidence, not payment.
• Ownership transfers require dual approval, step-up auth, notifications, and cooldown.
• No unclaimed mirrors at launch.
• Rate limits and review queues for new or risky publishers.
• Install and click analytics deduplicate obvious replay/bot traffic.
• Sponsored placement is queried and rendered separately from organic results.
• Paid promotion cannot change evidence state, organic score, moderation priority, or eligibility policy.
• Trademark, copyright, impersonation, malware, and license complaint workflows have published SLAs.

• Data classification: public, internal, confidential, restricted.
• Minimize personal data and public install telemetry.
• Encrypt data in transit and at rest; use field-level protection for recovery, tokens, and future payment/payout data where appropriate.
• Secrets live in a managed secret store, not repository files or general environment dumps.
• Audit access to restricted data and private artifacts.
• Retention and deletion policies distinguish user data from immutable public security history.
• Backups are encrypted, access-controlled, restored in tests, and covered by deletion policy.

Security-relevant events are immutable or tamper-evident:

• authentication, MFA, recovery, session and API-token events;
• membership/role/invitation changes;
• namespace and ownership changes;
• drafts, release authorization, publish, deprecate, revoke;
• signing and key events;
• scan/policy outcomes;
• administrative access and moderation decisions;
• promotion eligibility and placement decisions;
• private artifact and entitlement access when introduced.

Logs never include credentials, full tokens, component private source, or sensitive request bodies.

Alpha invitation bearer tokens are high-entropy, stored only as SHA-256 digests, rotated on resend, single-use, and time-limited. Acceptance atomically binds the invited email to its waitlist reservation, exact namespace, user, access record, lifecycle event, and Early Adopter badge. Revocation removes alpha access without deleting the historical invitation record.

• Reviewed data-flow diagram, threat model, data classification, and named security owner.
• Public/private dependency direction enforced.
• Security requirements traced to tests.

• ASVS-aligned auth/session review.
• Publisher/admin passkey or MFA and step-up flows operational.
• Recovery, account linking, session revocation, authorization, and rate-limit tests pass.

• Least-privilege GitHub App, signed/replay-protected webhooks, release authorization, transfer detection, and audit trail.

• Immutable versions, strict manifests, signatures, hashes, SBOM/dependency/license/secret scans, and revocation path.

• Malicious fixtures, path/symlink tests, signature failures, atomic rollback, and secure npm publishing independently reviewed.

• Independent sandbox penetration review before any third-party code is built or rendered.

• Incident response, signing-key compromise, account takeover, malicious release, takedown, backup/restore, and secret-rotation exercises.

• Legal, payment, entitlement, fraud, encryption/key, leakage, refund, and support review before hosted commercial source or payouts.

• Unclaimed mirrored listings.
• One broad “verified” or “secure” badge.
• Security claims for unseen closed source.
• Hosted paid-source storage/delivery.
• Creator payouts or marketplace custody.
• Arbitrary lifecycle/install scripts.
• Automatic/background component updates.
• Write-capable MCP installation.
• Long-lived install/download tokens.
• Query-string secrets.
• Arbitrary code previews before sandbox approval.
• Support impersonation without approval, audit, and user notification.

1. Stop further installs: revoke release/signing key and update client deny data.
2. Preserve evidence: immutable logs, artifacts, job records, and affected digests.
3. Notify affected creators/installers with exact versions and remediation.
4. Rotate exposed credentials and invalidate sessions/tokens.
5. Publish a factual incident record and root-cause/remediation timeline where appropriate.
6. Update fixtures, policies, and tests before restoring the affected capability.

• OWASP Software Supply Chain Security Cheat Sheet
• OWASP Application Security Verification Standard
• GitHub App private-key management
• Better Auth plugins
• Better Auth 2FA
• Better Auth organizations