N100FN100F
Published on

Code is surface too

Most of the code you deploy was not written by your organisation: it is dependencies, base images and third-party tooling. Knowing what each artefact contains, checking it on every build and signing what you publish closes a door almost nobody watches.

Service line Cybersecurity

The code nobody wrote

A modern application may have a few thousand lines of its own and hundreds of thousands of lines of dependencies: libraries, frameworks, operating system images. Each one may have known vulnerabilities, and some may have been tampered with deliberately before arriving.

Reviewing your own code is necessary. Ignoring everything else leaves most of the surface wide open.

What each artefact contains

What is inside what you publishOwn code, dependencies and base image pass through inventory, scanning, pinned versions and signing; a critical vulnerability stops publication.SECURITY · SUPPLY CHAINWhat is inside what you publish Own code4% of the code Dependencies81% of the code Base image15% of the codeBUILDComponent list612 libraries inventoriedVulnerability scan1 critical foundVersions pinnedallArtefact signatureonly if everything passesStoppednot publisheduntil the dependencyis updatedThe digest says what it is; the signature says who made it.With the list stored, 'are we affected?' is answered in minutes.Illustrative data; they do not correspond to any real caseN100F · n100f.com

The practice that solves this rests on the build itself, which is already an approval gate (as in let the build fail, not production):

  1. A component list. Every build generates an inventory of everything the artefact contains (usually called an SBOM): each library, with its version.
  2. Vulnerability scanning. That inventory is cross-referenced with the known vulnerability databases. Anything critical stops the build; the rest is recorded with a deadline.
  3. Pinned versions. Dependencies are pinned to specific versions, so that today's build and tomorrow's contain the same thing.
  4. A signed artefact. What gets published is signed, and the deployment accepts only artefacts signed by the build itself. It fits with deploying by digest: the digest says what it is; the signature says who made it.

What comes after deployment

A dependency with no vulnerabilities today may have them tomorrow, when a new one is discovered. Because every artefact in production has its component list stored, answering 'are we affected by this vulnerability?' is a query of minutes, not a days-long hunt across every repository.

Secrets and configuration too

The code you publish must not carry credentials inside it (we saw this in secrets by name, never by value), and infrastructure configuration is scanned just like application code, with rules as code.

With the software under control, what remains is protecting what matters most in the end: the data.

How we apply it: Cybersecurity.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk