Ed Rick

The CMMC cost squeeze on small DIB contractors is real, and it's starting to pull builders into the gap. Sherri shipped a free, open-source L1 self-assessment tool. Single HTML file, runs offline, nothing leaves your machine (architecture that is music to my ears). That trust posture (no telemetry, readable source) is exactly where compliance tooling for this market needs to go, and it's a principle I've built around myself: contractors handling sensitive data shouldn't have to phone home to prove they're compliant. More of this. The SMBs that keep the defense industrial base diverse can't be priced out of staying in it.

2

Petco disclosed that a setting in one of its software applications was misconfigured, which “inadvertently allowed certain files to be accessible online.” As a result, highly sensitive customer data was exposed. The data reportedly included names, Social Security numbers (SSNs), driver’s-license numbers, financial account information, credit/debit card numbers, dates of birth — essentially a full “identity theft toolkit.” Legal breach-notification filings show at least hundreds of affected customers in a single state (California), and smaller numbers in other states, although Petco served millions of customers annually, so the overall potential impact could be far larger. Petco claims to have “immediately” corrected the misconfiguration once discovered, removed the exposed files, notified affected customers, and offered free credit/identity-monitoring services.

3

1 Comment

I spend a lot of time with manufacturers and product teams who aren’t questioning whether they must comply with the Cyber Resilience Act (CRA) they’re stuck on the how. The CRA is clear on the obligations, but in practice the hard part is interpretation: software distributed online, products that depend on cloud back-ends, continuous updates, open-source components, product families, legacy models… This is exactly what the European Commission is trying to address now. The Commission is preparing a Communication (a guidance document) to explain how the CRA should be applied in real situations and to support a consistent approach across the EU. It’s not a new Regulation and it’s not “binding law” in itself but it matters because it clarifies how key provisions are expected to be understood and implemented in practice. https://lnkd.in/etm43Utx What I like in this draft is that it turns the CRA into practical “rules of the road”, especially on: • Software scope & “placing on the market” (including iterative releases) • What counts as the “product” when hardware depends on apps/drivers/software delivered separately • Open-source (FOSS): when it’s out of scope vs when it becomes a commercial activity, and the steward concept • Updates vs “substantial modifications”: focus on risk/attack surface/intended purpose, not release size • Support period: 5 years is a minimum, and how this works with versioned software/upgrade paths • Cloud / remote processing: what’s part of the product vs general IT infrastructure • Risk assessment & due diligence: manufacturers keep responsibility, including for third-party components The draft is open for feedback for a limited period, and comments are expected in a structured template (so they can consolidate input). If you build products that will fall under CRA, this is a very good moment to stress-test your assumptions and flag the parts that are unclear, unrealistic, or could lead to unintended consequences. I’m sharing the draft guidance here because, from what I see, the companies that will move fastest are the ones that turn these interpretations into concrete internal rules: scope mapping, update governance, support period policy, OSS governance, and evidence-ready documentation.

32

Audit readiness ≠ security readiness. They overlap — but they’re not the same thing. Audit readiness answers: “Can we prove we did the thing?” Security readiness answers: “Would the thing actually stop or detect the attack?” What audit readiness looks like: • Policies exist (and were reviewed). • Tickets show approvals happened. • Screenshots show a setting was enabled. • A sample of logs is attached. • A quarterly access review spreadsheet is signed. What security readiness looks like: • The control fails loudly when broken (alerts/tickets). • Coverage is continuous, not point-in-time. • Exceptions are time-boxed and tracked. • Owners have SLAs to remediate failures. • Incidents map back to scenarios (risk assumptions get updated). ⚠️ The common trap: We collect evidence that looks great… for controls that can still break silently. 💡 Practical move (do this with one control this week): Pick one “audit-ready” control and add one “security-ready” signal: • “Vulnerability scans completed” → Alert on critical vulns aging past SLA (e.g., >14/30 days). • “Backups exist” → Proof via restore test results (last restore date + time-to-restore). • “Security training completed” → Measure behavior: phishing failure rate trend + high-risk repeat. That’s how you satisfy audits and reduce real risk. Your leading question should be: “Would this control work on a bad day?”

7