Your Startup Ships More Code Than It Writes. Who Owns the Risk?

Your developers wrote the checkout flow. They probably did not write the framework, database driver, payment SDK, image library, authentication package, container base image, or the packages those packages dragged through the door.

That is normal. Reusing good software is how a small team gets anything shipped. The problem starts when “we use a lot of open source” becomes the entire risk-management strategy.

You can outsource the code. You cannot outsource knowing what your product depends on.

Why this belongs on a founder’s agenda now

In July 2026, CISA and its government partners released updated minimum elements for software bills of materials. The guidance adds detail about component identity, licenses, tooling and generation context, and addresses software including AI and SaaS. It is a useful direction of travel for software transparency, not a claim that every startup suddenly has the same legal obligation. Read CISA’s announcement.

The founder’s question is simpler: if a customer asks whether your deployed product contains a vulnerable component, can your team answer with evidence? Or does the meeting turn into six people searching Slack and one engineer saying, “I think we upgraded that”?

Start with the thing customers actually run

A software bill of materials—SBOM, because technology apparently charges by the acronym—is a component inventory. It can help connect a vulnerability notice to the software you use. Think ingredients list, not health certificate.

For a GitHub-hosted repository, GitHub can export the dependency graph as an SPDX-format SBOM. That is a practical starting point. Its usefulness depends on what the graph actually captures; check it against your deployed build, containers and dependencies that your tooling does not discover. GitHub explains the export options.

A list from today’s development branch is not automatically a list of what production ran last Tuesday. Tie the inventory to a release or build identifier. Keep it with the release evidence. State the gaps instead of dressing them up as completeness.

Five questions worth asking your technical lead

1. What is in the current production release? Ask for a dated inventory tied to a specific build, including important direct and indirect dependencies. “It is in the lockfile somewhere” is the start of an answer.
2. Who owns our most consequential dependencies? Name a person for authentication, payments, customer data, deployment and other critical paths. A vendor name is not your internal owner.
3. How do we decide which vulnerability needs action first? Look at whether the affected component is deployed, reachable, exposed to untrusted input and relevant to sensitive data. Do not confuse a long scanner report with a useful queue.
4. How does a fix reach production safely? Require a tested update, a deployment record and a rollback plan. Closing the ticket before the corrected release lands is paperwork cosplay.
5. What happens if the dependency stops being maintained? Identify alternatives and the cost of switching before an abandoned package becomes an emergency migration.

This is a leadership conversation about ownership, customer impact and response speed. Your founder dashboard does not need every package version. It needs the unresolved risks that could interrupt revenue, expose customer data or stall a deal.

A manageable assignment for this week

Pick one customer-facing product and its current production release. Ask the team to produce the best available inventory, record what is missing, and choose three dependencies whose failure would hurt the business most.

For each, write down the owner, installed version, update route, relevant open issues and how a change would be tested. Then walk through one real advisory or maintenance warning together. Can you establish whether it applies, who decides, and how you would prove the replacement was deployed?

Do not promise yourself a perfect enterprise program by Friday. Get one release traceable and one response process usable. Repeat the inventory step for subsequent releases and review the meaningful exceptions.

Keep the inventory useful, not theatrical

Do not put credentials, private configuration or customer data into an SBOM. Share it through the channel appropriate to your customer agreement and security review. Be candid about coverage and freshness.

And do not buy a dashboard before agreeing on who acts on it. A beautifully categorized dependency nobody owns is still a dependency nobody owns.

My rule: If your team cannot connect the ingredient, the release and the person responsible, your software supply chain is a frickin’ guessing game.