The Risk Nobody Sees Coming
Software Development · AI Coding · Supply Chain Security

You built the product.
Everyone downstream is running your risk.

You didn't inherit the software supply chain problem. You became it. Every line of code you ship lives in your customers' infrastructure — and so does every vulnerability you didn't catch.

See How ISERA Applies → The 5 Questions to Ask
The Structural Flaw

Two models. One conversation most software leadership teams never have.

Most software companies think supply chain risk is something that happens to them — through their dependencies. The reframe: they are the supply chain for everyone downstream. Their customers are running their security decisions in production right now.

How Most Software Companies Operate

The Ship-and-Patch Model

Move fast. Deploy continuously. Treat security review as friction. AI coding tools adopted developer by developer, without governance policy. Open-source dependencies pulled without provenance checks. SOC 2 initiated when an enterprise prospect demands it. Change management documented retroactively — if at all. Security as gatekeeper at the end of the pipeline.

What Security-Governed Software Companies Build

The Governed SDLC

Security requirements defined at design, not discovered at audit. AI-generated code treated as untrusted external contribution — mandatory review, SAST/DAST, provenance tracked. SBOM generated at every build. Change management evidence that answers: who authorized this commit, and how do we prove it? SOC 2 as a competitive advantage, not a compliance tax.

"Software companies aren't just building products anymore. They're building the infrastructure their customers run on. That changes what 'your security program' means — because your security gaps don't stay in your codebase. They propagate downstream."

Steve Weltman, CISSP  ·  Founder, Aletheia Security Consulting

45%
of AI-generated code
contains security flaws
Veracode 2025
30%
of all breaches now involve
a third party — doubled YoY
Verizon DBIR 2025
267 days
average time to detect
a software supply chain breach
Ponemon Institute 2025
Dec 2027
EU Cyber Resilience Act full compliance deadline — fines up to €15M
EU Regulation 2024/2847
A Better Conversation

The 5 questions your enterprise buyers are already asking.

Every question below maps to something an auditor, a procurement team, or an enterprise customer has already started checking. Most software companies can't answer them yet.

The SDLC Anatomy

Every software company has the same architecture.

The development process is the product of your security program — not just your running application. This is what we examine.

Software Component Security Domain What We Assess
Codebase and repositories The product itself AI-generated code governance, review parity, secret scanning, CWE density
CI/CD pipeline The assembly line Build integrity, artifact signing, deployment gates, unauthorized modification risk
Open-source dependencies Third-party supply chain Component provenance, SBOM completeness, malicious package exposure, version currency
AI coding tools in use The new contributor Policy coverage, shadow AI inventory, output governance, training data exposure
Change management system The audit trail Commit attribution, approval workflow, test evidence, CC8.1 / ISO A.14 compliance
Developer workstations and tooling The entry point IDE extensions, toolchain integrity, credential hygiene, secret management
Vulnerability disclosure process The response capability Patch velocity, customer notification readiness, EU CRA reporting compliance
The Assessment

The visibility your customers need. The evidence trail your auditors will find.

Information Security Enterprise Risk Assessment (ISERA)

A 30-business-day structured assessment that examines the system most software companies have never had independently evaluated: the development process itself. Workshops with engineering leadership, DevOps, and product management. A perception gap analysis that reveals where the engineering team and business leadership see security risk differently — they always do. A risk register built from your actual SDLC. A prioritized roadmap your board can govern with.

AI coding tool inventory and governance gap analysis
SBOM readiness assessment against EU CRA and enterprise buyer requirements
CC8.1 change management evidence audit — what an auditor would find today
Open-source dependency risk and provenance exposure
Vulnerability disclosure program readiness review
Perception gap analysis — where engineering and leadership see risk differently

Satisfies risk assessment requirements across:

SOC 2 Type II ISO 27001:2022 NIST SSDF EU Cyber Resilience Act ISO 42001 NIST CSF 2.0
Request a Scoping Conversation →
Common Questions

What software companies ask us before they engage.

Do we need to be pursuing SOC 2 or ISO 27001 to benefit from an ISERA?

No. The ISERA is explicitly designed to be valuable whether or not you're pursuing a formal certification. Many software companies engage us specifically because they need to understand their real risk posture before deciding which framework — if any — makes sense for their business. The ISERA gives you a prioritized picture of where you're exposed, what it costs you, and what to address first. Certification is a separate decision.

We already passed a SOC 2 audit. Why would we need this?

Because the audit assessed your controls as documented — not your current development process. If you've adopted AI coding tools, expanded your engineering team, added open-source dependencies, or changed your CI/CD pipeline since your last audit, your control environment has changed. The ISERA tells you whether your documented controls still match reality. Most of the time, they don't perfectly.

How is the ISERA different from a penetration test?

A penetration test finds exploitable vulnerabilities in your running systems. The ISERA examines the governance, process, and evidence structure of your security program — your SDLC, change management controls, risk register, and third-party dependencies. The two are complementary. We frequently recommend pen testing as part of the roadmap we produce, but we don't conduct one ourselves during the ISERA.

What do we walk away with after 30 business days?

Four deliverables: a risk register grounded in your actual environment (not a generic template), a prioritized remediation roadmap your board can govern with, a perception gap analysis showing where engineering leadership and business leadership see risk differently, and board-ready reporting in business language. No 200-page findings dump. A working document your team can execute against.

We're a 15-person startup. Is this for us?

Yes — and arguably more so than for an established company. The cost of remediating security debt compounds with company size. A startup that discovers its AI-assisted SDLC has a change management gap can fix it in weeks. An enterprise with the same gap remediates it over 18 months under audit pressure. The ISERA is sized to your organization, not to a Fortune 500 compliance checklist.

Stop shipping security debt
alongside your features.

The enterprise buyers asking for your SOC 2 report, the EU customers triggering your CRA obligations, the auditor who will eventually ask who authorized that commit — they're all asking the same question: can you prove your development process is governed? Let's find out where you stand before they do.

Talk to Aletheia Security →