We assessed Meridian Labs (Sample)'s codebase — 3 files and 0 third-party dependencies — across seven domains: hardcoded credentials, configuration and infrastructure, dependency vulnerabilities, dependency licensing, git history, security-readiness process evidence.
Overall security grade: C. Workable, but at least one issue here would be raised by a buyer's security team. Startup readiness score: 0% — “Pre-security”. Security process evidence is largely absent. The good news: most of the missing items are files and configuration, not months of engineering.
7 of the findings are quick wins — single-file or single-setting fixes, most automatable with `dira fix --apply`.
Nothing found here is unusual for a company at this stage — what matters to an enterprise buyer is the trajectory. Close the Week 1 items, re-run the scan, and you walk into the next security questionnaire with evidence instead of promises.
P0 fix this week · P1 this month · P2 this quarter · P3 housekeeping. One row per issue type; counts show total occurrences.
| Priority | Finding | Impact | Effort | What it means / what to do |
|---|---|---|---|---|
| P1 | high SQL built by string concatenation setup_fixture.sh:30 | High | Low | A misconfiguration that widens your attack surface or fails a security review. Fix: Use parameterized queries / bound placeholders. |
| P1 | high TLS verification disabled setup_fixture.sh:34 | High | Low | A misconfiguration that widens your attack surface or fails a security review. Fix: Never disable certificate verification; pin a CA bundle instead. |
| P2 | medium Missing: Dependencies are lock-pinned | Moderate | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Commit a lockfile (package-lock.json / uv.lock / poetry.lock / Cargo.lock). |
| P2 | medium Missing: Automated dependency updates | Moderate | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add .github/dependabot.yml or renovate.json. |
| P2 | medium Missing: Secret scanning in CI | Moderate | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add dira / gitleaks / trufflehog as a required CI job and a pre-commit hook. |
| P2 | medium Missing: Automated tests present | Moderate | High | Missing process evidence a buyer's security questionnaire asks for. Fix: Add a tests/ directory and wire it into CI. |
| P3 | low Missing: Code review ownership defined | Low | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add a CODEOWNERS file and require review on the default branch. |
| P3 | low Missing: Vulnerability disclosure policy | Low | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add SECURITY.md with a contact address and response SLA. |
| P3 | low Missing: Continuous integration configured | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Add a CI workflow that installs, lints, and tests on every PR. |
| P3 | low Missing: Static analysis / code scanning | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Enable CodeQL, Semgrep, bandit, or gosec in CI. |
| P3 | low Missing: Error tracking / monitoring wired in | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Wire in Sentry, OpenTelemetry, Datadog, or equivalent, with alerting. |
| P3 | low Missing: Incident response / runbook documented | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Add docs/INCIDENT-RESPONSE.md: severities, on-call, comms, 72h notification path. |
| P3 | low Missing: Backup / recovery documented | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Document backup schedule, retention, and a tested restore procedure. |
| P3 | low Missing: Infrastructure as code | Low | High | Missing process evidence a buyer's security questionnaire asks for. Fix: Move infra into Terraform / Pulumi / CloudFormation / compose files. |
| P3 | low Missing: Vetted auth implementation | Low | High | Missing process evidence a buyer's security questionnaire asks for. Fix: Use a vetted provider/library (Auth0, Clerk, Supabase Auth, NextAuth, Devise, Django auth). |
| P3 | info Missing: Pre-commit hooks | Low | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add .pre-commit-config.yaml (or husky) with a secret-scan hook. |
| P3 | info Missing: Config documented without secrets | Low | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add .env.example listing every required variable with empty values. |
| P3 | info Missing: License declared | Low | Low | Missing process evidence a buyer's security questionnaire asks for. Fix: Add a LICENSE file. |
| P3 | info Missing: Reproducible build/runtime definition | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Add a Dockerfile (non-root, pinned base image). |
| P3 | info Missing: Privacy policy / data handling documented | Low | Medium | Missing process evidence a buyer's security questionnaire asks for. Fix: Publish a privacy policy and record what personal data you store and where. |
0 of 80 points · 18 checks weighted by what enterprise security reviews actually ask.
| Check | Pts | Why it matters / how to close it | |
|---|---|---|---|
| ✘ | Dependencies are lock-pinned | 6 | Unpinned deps mean an attacker who takes over a maintainer account ships straight to prod. Close it: Commit a lockfile (package-lock.json / uv.lock / poetry.lock / Cargo.lock). |
| ✘ | Automated dependency updates | 6 | Most breaches start with a known CVE nobody upgraded. Close it: Add .github/dependabot.yml or renovate.json. |
| ✘ | Continuous integration configured | 5 | No CI means nothing is verified before it ships. Close it: Add a CI workflow that installs, lints, and tests on every PR. |
| ✘ | Automated tests present | 6 | Security fixes you cannot regression-test get silently reverted. Close it: Add a tests/ directory and wire it into CI. |
| ✘ | Secret scanning in CI | 8 | Committed keys are the single most common startup breach; catch them before merge. Close it: Add dira / gitleaks / trufflehog as a required CI job and a pre-commit hook. |
| ✘ | Static analysis / code scanning | 5 | Buyers ask for evidence of SAST in every security questionnaire. Close it: Enable CodeQL, Semgrep, bandit, or gosec in CI. |
| ✘ | Pre-commit hooks | 3 | The cheapest place to stop a secret is the developer's laptop. Close it: Add .pre-commit-config.yaml (or husky) with a secret-scan hook. |
| ✘ | Code review ownership defined | 4 | Unreviewed merges to main are the top finding in SOC 2 change-management. Close it: Add a CODEOWNERS file and require review on the default branch. |
| ✘ | Vulnerability disclosure policy | 4 | Researchers need a place to report; auditors check for one. Close it: Add SECURITY.md with a contact address and response SLA. |
| ✘ | Config documented without secrets | 3 | An .env.example proves config is externalised rather than hardcoded. Close it: Add .env.example listing every required variable with empty values. |
| ✘ | Infrastructure as code | 4 | Click-ops infrastructure cannot be reviewed, diffed, or restored. Close it: Move infra into Terraform / Pulumi / CloudFormation / compose files. |
| ✘ | Reproducible build/runtime definition | 3 | A Dockerfile makes the runtime auditable and patchable. Close it: Add a Dockerfile (non-root, pinned base image). |
| ✘ | Error tracking / monitoring wired in | 5 | You cannot respond to an incident you never see. Close it: Wire in Sentry, OpenTelemetry, Datadog, or equivalent, with alerting. |
| ✘ | Vetted auth implementation | 4 | Hand-rolled auth is where startups lose customer data. Close it: Use a vetted provider/library (Auth0, Clerk, Supabase Auth, NextAuth, Devise, Django auth). |
| ✘ | Incident response / runbook documented | 5 | Enterprise contracts require a documented breach-notification process. Close it: Add docs/INCIDENT-RESPONSE.md: severities, on-call, comms, 72h notification path. |
| ✘ | Backup / recovery documented | 4 | Ransomware and a bad migration have the same fix: tested restores. Close it: Document backup schedule, retention, and a tested restore procedure. |
| ✘ | Privacy policy / data handling documented | 3 | Required before you can legally take EU or enterprise customer data. Close it: Publish a privacy policy and record what personal data you store and where. |
| ✘ | License declared | 2 | Diligence flags unlicensed code as an IP risk. Close it: Add a LICENSE file. |
When an enterprise prospect sends a security questionnaire, these are the questions behind it. “Evidenced” means this assessment found repository evidence you can point to; “gap” means answer honestly and attach the roadmap date. Buyers accept gaps with dates — they reject surprises.
| Status | Buyer question | SOC 2 control | Your answer today |
|---|---|---|---|
| Gap | Do you pin and verify third-party dependency versions? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Commit a lockfile (package-lock.json / uv.lock / poetry.lock / Cargo.lock). |
| Gap | How do you identify and remediate vulnerable dependencies? | CC7.1 — Vulnerability management | Not yet — say so, and commit to a date. Close it: Add .github/dependabot.yml or renovate.json. |
| Gap | Are changes built and tested automatically before deployment? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Add a CI workflow that installs, lints, and tests on every PR. |
| Gap | Do you maintain automated tests that run before release? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Add a tests/ directory and wire it into CI. |
| Gap | What controls prevent credentials from being committed to source code? | CC6.1 — Logical access controls | Not yet — say so, and commit to a date. Close it: Add dira / gitleaks / trufflehog as a required CI job and a pre-commit hook. |
| Gap | Do you perform static application security testing (SAST)? | CC7.1 — Vulnerability management | Not yet — say so, and commit to a date. Close it: Enable CodeQL, Semgrep, bandit, or gosec in CI. |
| Gap | What controls run on developer machines before code is pushed? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Add .pre-commit-config.yaml (or husky) with a secret-scan hook. |
| Gap | Is peer review required before changes reach the default branch? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Add a CODEOWNERS file and require review on the default branch. |
| Gap | Do you operate a vulnerability disclosure process with a response SLA? | CC2.3 / CC7.3 — Communication & incident reporting | Not yet — say so, and commit to a date. Close it: Add SECURITY.md with a contact address and response SLA. |
| Gap | Is application configuration externalised from source code? | CC6.1 — Logical access controls | Not yet — say so, and commit to a date. Close it: Add .env.example listing every required variable with empty values. |
| Gap | Is infrastructure defined as code and subject to review? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Move infra into Terraform / Pulumi / CloudFormation / compose files. |
| Gap | Are build and runtime environments reproducible and auditable? | CC8.1 — Change management | Not yet — say so, and commit to a date. Close it: Add a Dockerfile (non-root, pinned base image). |
| Gap | How do you detect, alert on, and investigate anomalous activity? | CC7.2 — System monitoring | Not yet — say so, and commit to a date. Close it: Wire in Sentry, OpenTelemetry, Datadog, or equivalent, with alerting. |
| Gap | How is authentication implemented, and is it a vetted provider or library? | CC6.1 — Logical access controls | Not yet — say so, and commit to a date. Close it: Use a vetted provider/library (Auth0, Clerk, Supabase Auth, NextAuth, Devise, Django auth). |
| Gap | Do you have a documented incident response plan including customer notification timelines? | CC7.3 / CC7.4 — Incident management | Not yet — say so, and commit to a date. Close it: Add docs/INCIDENT-RESPONSE.md: severities, on-call, comms, 72h notification path. |
| Gap | Describe your backup schedule, retention, and most recent tested restore. | A1.2 — Availability & recovery | Not yet — say so, and commit to a date. Close it: Document backup schedule, retention, and a tested restore procedure. |
| Gap | Do you publish a privacy policy and maintain a record of personal data processing? | P1–P8 — Privacy criteria | Not yet — say so, and commit to a date. Close it: Publish a privacy policy and record what personal data you store and where. |
| Gap | Is the intellectual-property status of your codebase and dependencies documented? | CC1.x — Governance (IP diligence) | Not yet — say so, and commit to a date. Close it: Add a LICENSE file. |
These cannot be verified from code. Complete and keep them current; every serious questionnaire asks.
Static analysis of ~/src/meridian-labs — 3 files, ruleset v1.5.0, 0.02s. Scanners: hardcoded credentials (pattern + entropy, redacted), configuration/IaC, dependency CVEs via OSV.dev, dependency licensing, git history, security-readiness process evidence, and live TLS/header checks where a target was authorized.