Questions

Q: What is Strig?

Strig watches the build as it runs — software supply chain security for compiled, embedded, and safety-critical systems. The source tree does not describe what actually compiles and links. Strig records that moment, then turns it into quieter reviews, prioritized risk, and signed artifacts.

Q: What is the Build Truth Layer?

The Build Truth Layer is Strig's foundation: a trusted system of record for everything that enters a build, every compile and link event during it, and every artifact that comes out.

Q: How is Strig different from SAST or SCA tools?

SAST and SCA tools typically read source, scan binaries, or trust a lockfile. Compiled languages do not have a lockfile that matches what linked. Strig watches the build itself, where flags, supplier code, and toolchain choices determine what actually ships.

Q: Does Strig use AI to make release decisions?

Strig uses AI to assess findings and draft remediations, but the release gate never consults a model. The pass-or-fail verdict comes from policy applied to signed build evidence.

Q: Why do we need this when AI tools exist?

AI can only read what is written down. The build never writes down what it did. Show an AI your source and it checks code that may never be compiled; show it the finished file and it can only guess. Strig records the build, turns it into signed evidence, and analyses it. Better models do not remove the need for that sensor.

Q: Which data does not exist unless something captures it?

Compile and link commands, exact flags, what actually linked, real dependencies including vendored and statically linked code, which compiler and machine produced each artifact, every host the build reached, and crashes from fuzzing real binaries. None of this is in the source tree or the finished binary. Strig captures it as a hashed, signed record an auditor can accept.

Q: Why not just use a general-purpose model like Claude or GPT?

Evidence checks are deterministic lookups against reference data Strig maintains, not a general model over the build. The same build produces the same result; every finding points to a record; CVE data stays current; lookups run in milliseconds in CI. A general model sits only in the advisory layer. It never touches the gate.

Q: Our builds are air-gapped. Does any of this still work?

Yes. Lookups and reference data run where the build runs. Strig blocks its own network access during a scan. A hosted general model needs an outbound API call and cannot work behind an air gap. CVE feeds refresh as an offline update. Deploy on-premise, fully air-gapped, or as SaaS.

Question 1

Why is compiled and native development so poorly controlled?

Answer

Unlike backend and cloud systems, the sources do not tell you what you shipped. A compiled build also depends on:

The toolchain and its version. The same source built with a different compiler produces different code.
Build flags. Hardening on or off, optimization level, debug instrumentation left enabled — none of it visible in the repository.
Third-party binaries. Prebuilt libraries dropped into the tree, never compiled from source you hold.
Which code is actually compiled. The same file means different things depending on the defines, include paths and target. Half of it may be switched off in your build.

This is also why scanning the source tree alone falls short: a tool that has not seen the build has to guess all of the above, and it usually guesses wrong — so it checks a version of your code that nobody builds.

Question 2

Why is analyzing a compiled binary harder than a cloud package?

Answer

A cloud package is a known, standard format. Tools can open it, read a manifest, and list what is inside.

Compiled binaries often are not. Firmware is the sharpest example.

The format is often proprietary. No standard layout, sometimes compressed or signed in a vendor-specific way — so the artifact you actually ship is the hardest part of the system to open at all.
It can be a whole operating environment, not just code. A firmware image also carries its configuration: user accounts and permissions, firewall rules, access control policy, enabled services, startup scripts, keys and certificates.

That configuration is a real part of your attack surface. A correct binary with a wide-open firewall rule, a default account, or a debug service left enabled is still an insecure product — and none of it appears in the source code or in any dependency list.

Question 3

Why is detecting third-party dependencies so hard here?

Answer

There is no manifest and no lockfile listing what went in.

Dependencies arrive as vendored folders, as code copied from a repository and then edited, and as prebuilt binaries. Nothing records where any of it came from or which version it was — so there is nothing to check it against later.

Question 4

Why are the existing tools insufficient?

Answer

They are fragmented. Each one does a single check — code analysis, or dependency analysis. You buy several and reconcile their reports yourself.
Some checks are missing entirely. Third-party binaries, toolchain authenticity, and what was actually linked into the image are not covered by any of them.

Question 5

These tools give us thousands of findings. How is anyone supposed to handle that?

Answer

You can’t. A raw list of thousands is not a security result, it is an unsorted backlog.

The problem is that it isn’t ranked. Whether a finding actually matters depends on questions the code alone can’t answer:

Is this code reachable at runtime?
Does it ship in the product, or is it only used at build time?
Is it exposed to anything an attacker can touch?

Answering those requires knowing the system architecture, not just the source. You declare the exposure model once — what is exposed, what an attacker can reach — and Strig uses it with build truth.

Strig cross-correlates findings against that architecture and what actually built, so what comes back is prioritized by actual risk to your product — not handed over as a flat list.

Question 6

How does Strig know my architecture?

Answer

We do not invent it. You declare the exposure model once — what is exposed, what an attacker can reach. Threat modeling stays a human decision. Strig uses that declaration with build truth to rank findings.

Question 7

What is Strig?

Answer

Software supply chain security for compiled, embedded, and safety-critical systems. Strig watches the build as it runs, recording what entered, every compile and link, and every artifact that left. It then runs SAST, SBOM, CVE tracking, and binary analysis in one report and one gate. Signed evidence ties to the exact binary you shipped. Run the same build again and the evidence matches.

Question 8

Who is Strig for?

Answer

Teams shipping compiled, embedded, and safety-critical systems, where the build determines what goes out the door: R&D and DevSecOps (integrate without friction), Product Security (prioritize real risk), CISO (software supply-chain visibility), and Quality & Compliance (signed evidence for audits).

Question 9

How can Strig be deployed?

Answer

Three ways: on-premise, fully air-gapped, or SaaS. Same platform, your choice. On-prem and air-gapped deployments keep your source, binaries, and build records inside your network; Strig blocks its own network access during scans. SaaS runs on managed infrastructure when you want speed without operating servers. Data handling, residency, and connectivity: we adjust to your requirements.

Question 10

How do I get started?

Answer

Request access for a pilot, or contact us to discuss your build and compliance requirements.

Question 11

How is Strig licensed?

Answer

Licensed per your environment. Contact us for pricing. It depends on your build volume and deployment model.

Question 12

What happens when Strig finds a problem?

Answer

Findings land in one report, ranked by actual risk: architecture context first changes feasibility, then damage scenarios change impact. Highly feasible findings of low impact are not the work. Your team triages and remediates; Strig does not change your code. If policy thresholds are exceeded, the release gate fails and CI gets a non-zero exit code. Signed evidence is produced either way.

Question 13

Why do we need this when AI tools exist?

Answer

AI can only read what is written down. The build never writes down what it did. It happens, it ends, and the record is gone. Your repository never had it, and the finished file does not give it back.
So it matters what you show the AI. Show it your source code, and it checks code that may never be compiled. Show it the finished file, and it can only guess what the build did. Show it what Strig recorded — whether that is our analysis or your own — and it checks what you really shipped.
We are the sensor and the analysis. Strig records that moment, turns it into signed evidence you can hand an auditor, and analyses it with models of our own. The sensor is the part nobody can replace: better models do not remove the need for it, the same way better vision models did not remove the need for cameras. Something still has to be there when it happens.

Question 14

Which data does not exist unless something captures it?

Answer

None of this is in your source tree, and none of it survives in the finished binary. It exists while the build runs:

Every compile and link command that actually ran
The exact flags applied to each file
What actually linked into the shipped binary
The real dependencies, including vendored and statically linked code
Which compiler and linker produced each artifact, and on which machine
Every host the build reached
Crashes from fuzzing the real binaries

A tool can be wired into a compiler to watch some of this. The hard part is not connecting. It is producing a complete record, hashed at capture, signed at capture, that an auditor accepts and a release decision can rest on. That record is what Strig hands you, and it is what any analysis, human or machine, needs in order to reason about the product you are actually shipping.

Question 15

Why not just use a general-purpose model like Claude or GPT?

Answer

We do not run a general model over your build. The checks that produce evidence are deterministic lookups against reference data we maintain: component fingerprints, known binaries, CVE and advisory feeds. Five reasons that matters.

Deterministic. The same build produces the same result every time. A hosted general model changes under you without notice, and you cannot certify against a moving target.
Traceable. Every finding points to a specific record, not to a model's judgement. When an auditor asks why, there is an answer that does not depend on trusting a model.
Current. Vulnerabilities are disclosed daily. A general model is frozen at its training cutoff and will not know about a CVE published last week. Our reference data refreshes continuously, so today's build is checked against today's disclosures.
Fast. This runs in CI, on every build. A lookup returns in milliseconds. A general model is too slow to sit in a pipeline.
Affordable. A lookup costs almost nothing, so scanning every build stays viable instead of billing model inference per build.

A general model sits only in the advisory layer, where it explains and ranks findings. It never touches the gate.

Question 16

Our builds are air-gapped. Does any of this still work?

Answer

All of it. This is exactly where an AI-first approach falls apart and ours does not.

Nothing leaves your network. The lookups and the reference data run where your build runs. We block our own network access during a scan, so your source and binaries cannot go anywhere even by accident.
No cloud model to call. A tool built on a hosted general model needs an outbound API call to do its job. Behind an air gap it has nothing to call, and the analysis it advertises simply does not happen. A local lookup against local reference data has no such dependency.
Reference data updates offline. CVE and advisory feeds refresh on your schedule, delivered as an offline update, so an isolated network is still checked against current disclosures.

Deploy on-premise, fully air-gapped, or as SaaS. Same platform, same results.

Question 17

What are the main benefits?

Answer

One holistic solution. SAST, SBOM, CVEs, and binary analysis in one report and one gate, instead of a stack of tools that contradict each other.

Accuracy. We report on code that is actually compiled and linked, so you are not triaging findings in code that never shipped.

The parts your own build list doesn't show. Vendored code, statically linked libraries, and transitive dependencies go missing even in well-run teams. Strig finds them because it watches what actually gets compiled and linked.

Evidence. Signed records tied to the exact binary you shipped. Run the same build again and the evidence matches.

Question 18

How is your SAST and SCA different from others?

Answer

More accurate, because we only analyze what is actually built.

Compiled and linked. Findings in code that never made it into the product are demoted or dropped.
Architecture context. Feasibility is dropped or lowered where a finding cannot be used here. Damage scenarios then revise impact. Risk is both — not code reachability alone.
Exact code, not manifests. Our SCA identifies the actual compiled code snippets that shipped, rather than trusting a dependency manifest that says what should be there.

Question 19

How is Strig different from the tools already on the market?

Answer

Those tools inventory from manifests. Compiled languages create inventory at compile and link. Strig watches that moment.
One solution, not a stack. One report and one gate, instead of three tools whose reports your engineers have to reconcile.
We see the actual build; they don't. Other tools scan the source tree or the binary and guess.
Findings you can act on. Architecture context drops or lowers feasibility, then revises impact. A reachable finding of low impact is not the work. Other tools stop at code reachability, or report everything, so you still have to triage.
Some checks are only possible from the build. Build provenance, toolchain authenticity, modified vendored code, debug instrumentation left in a release. None of it is visible from source or binary alone.

Regulations like the CRA and sector frameworks turned software inventory from good practice into an obligation, including for products you already sold.

Question 20

How is this different from software supply chain tools?

Answer

Most supply chain tools trust a lockfile from npm, PyPI, or a container image. Compiled, low-level languages do not have a lockfile that matches what linked. Vendored copies, static libraries, and the toolchain decide the inventory at compile and link. Strig watches that moment, then still runs SAST, SBOM, CVE tracking, and a release gate on what actually built.

Question 21

Which standards and frameworks do you support?

Answer

Evidence for programs across automotive, medical, industrial, rail, and embedded, including ISO 26262, IEC 62304, IEC 62443, EU CRA, FDA cybersecurity guidance, MISRA, and CWE, among others. We produce evidence for your assessor; we do not certify you. Don't see your framework? Tell us. Adding coverage is routine engineering work.

Question 22

Does this replace our current tools?

Answer

It is a holistic solution, so it can replace a fragmented stack, or it can be integrated alongside the tools you already run.

Question 23

Why now, and not five years ago?

Answer

Three shifts at once:

Compliance. The CRA and sector frameworks turned software inventory and vulnerability handling from good practice into an obligation, including for products you already sold.
AI-generated code. Volume of code to review outpaced anyone's ability to account for what's in it.
IoT. A step change in connected physical devices (thermostats, vehicles, medical devices, industrial controllers), each running embedded software with a long-lived attack surface.

Question 24

Does Strig modify our build?

Answer

No. Strig watches the build and records what happens. It does not change compiler flags, sources, or build steps.

Question 25

Is the binary we ship still bit-for-bit what it would have been?

Answer

Yes. The output is unchanged, with the same artifact hash. Strig observes and does not rewrite. We produce evidence that the observed build yielded the same artifact as the unobserved one.

Question 26

Which compilers do you support?

Answer

Major C and C++ toolchains today. Other compiled languages as your builds need them. Tell us what you compile with and we will confirm.

Question 27

Which build systems do you support?

Answer

Any build system that invokes real compiler and linker commands, including Make, CMake, Bazel, Yocto, Ninja, and the rest. Strig captures what actually runs during the build. It does not care how those commands were orchestrated.

Question 28

How much slower is the build?

Answer

Seconds of overhead in the worst case. Strig records while your build runs; it does not add build steps.

Question 29

Will it disrupt our workflow?

Answer

No. Strig runs in parallel with your existing CI/CD, with no conflict and no intrusion into your process. You run the same build command under Strig: strig <build command>. No pipeline rewrite. Seconds of overhead in the worst case. Your pipeline gets a pass/fail exit code.

Question 30

Does Strig fuzz our binaries?

Answer

Yes. Strig fuzzes the binaries your build actually produces, not a source-level approximation. Crash results feed the same report and gate as SAST, SCA, and SBOM findings.

Question 31

Which checks are impossible without watching the build?

Answer

These have no source-only or binary-only equivalent. The evidence exists for one moment, while the build runs, and is gone afterward.

Compiler and linker flags. Whether hardening was on and debug instrumentation was left in. The build files say what was intended; only the build says what was passed.
Third-party binary artifacts. Prebuilt libraries and objects linked in without ever appearing in a dependency manifest.
Suspicious build commands. A build step that downloads a file and pipes it straight into a shell. It exists only as a command that ran; nothing is left in the source tree to find.
Downloads from untrusted sources. Every host the build reached, and whether what came down was then compiled, linked, or executed. This is the xz-utils shape: the download and its use are separate events, innocuous apart, and only the build record connects them.
Reachability. Which code was actually compiled and linked, so a CVE in code that never shipped is dropped rather than triaged.
Toolchain provenance. Which compiler and linker actually produced each artifact, rather than which one the build files name.
Build-machine state and drift. Whether the host was altered mid-build — source swapped, then restored. Repo integrity checks can still pass; only build observation sees the swap.
Fuzzing. Building a fuzzable target requires the real compile and link commands.

Everything else — source scanning, manifest parsing, secret detection, finding modified vendored code — can be done without the build. It is just less accurate.

Question 32

Where does our data go?

Answer

Depends on how you deploy. On-prem and air-gapped: everything stays in your network. SaaS: processed in Strig-managed infrastructure, configured to your requirements. Tell us your constraints and we will match them.

Question 33

Do you collect information about our software?

Answer

On-prem and air-gapped: nothing leaves your environment by design. SaaS: governed by your deployment agreement. We adjust to your requirements.

Question 34

Can it run air-gapped?

Answer

Yes, that is the design intent. The operational details (how vulnerability data updates arrive and how licensing is handled offline) are being finalized. We will confirm those specifics rather than guess at them.

Question 35

We have products already in the field. Does Strig only help from the next release onward?

Answer

Not only. If you still have the source and the toolchain for a past release, that release can be rebuilt under observation and produce evidence for the image that actually shipped. Where source or toolchain is gone, the value is forward-looking, from the next maintenance release onward.

Question 36

What does that give us for a product already sold?

Answer

An inventory of what is genuinely inside the shipped image, the known vulnerabilities affecting it, and a comparison against whatever inventory you hold today.

Try it on your build