Products / StackAttest
Building an assurance product forces a precision that is easy to avoid elsewhere. Every claim needs a source, every score needs a method, and every limit has to be stated rather than implied.
StackAttest is a software validation product published by Tech Steps LLC. It gathers evidence from a live application, its source, its dependency graph and an isolated runtime, maps what it finds to named security and engineering standards, and produces a Passport the publisher controls. It appears here because building it required solving problems in evidence architecture, honest scoring and AI system design that carry directly into client work.
The problem we were solving
A working demo, a green test suite and a deployed URL are all compatible with an application that has no access control worth the name, dependencies with known vulnerabilities, no recovery path and no way to tell what is happening inside it.
That gap has always existed. It widened as more software began to be assembled quickly, because the speed of producing something that runs increased faster than the speed of verifying that it should be trusted.
The people who need to judge that, a founder deciding whether to launch, an accelerator reviewing a portfolio, a buyer performing diligence, are usually not in a position to read the codebase. They need evidence, not assurance, and evidence that says what it did not check as clearly as what it did.
Evidence sources
Each source answers questions the others cannot. Reading source code tells you nothing about what the deployed instance actually exposes.
What the running application actually exposes, tested from outside as an ordinary client would reach it.
The code itself, examined for the patterns that map to named weakness classes.
What the application pulls in, which is where a substantial share of real-world risk lives and where teams have the least visibility.
The application run in a controlled environment, because some properties only appear when the software is executing rather than being read.
Decisions and their reasons
Most of these made the product harder to build and easier to defend. That is usually the right trade in assurance work.
A private scoring system is unauditable by design. Mapping findings to OWASP ASVS, NIST SSDF, CWE, the OWASP API Security Top 10, WSTG and SLSA means a reader can go and check what the control actually requires. It also means we cannot quietly move the goalposts, which is the point.
Because a number that drifts with model opinion is not a measurement. The score is computed from evidence deterministically. Model review runs alongside it and reports agreement, objection and minority opinion, and consensus never changes the score. Mixing the two would produce a figure nobody could reproduce.
A single model is a single point of view with a consistent set of blind spots. Multiple independent reviewers surface disagreement, and disagreement is information. Reporting where reviewers objected is more useful than presenting a smoothed consensus that hides it.
A score alone hides how much was actually examined. Reporting score, evidence coverage, validation confidence and model consensus separately lets a reader see the difference between a high score on thin evidence and a high score on thorough evidence. Compressing those into one number destroys exactly the information a serious reader wants.
Because readiness is not binary. Levels from registration through external, code, runtime and production validation describe how far verification actually went. A binary badge would flatten a real distinction and encourage claiming more than was tested.
Validation output that the subject cannot publish or withhold is not something anyone would run honestly on their own product. Founder control over publication, with the evidence trail intact, is what makes the process something teams will actually use before they are forced to.
The boundary we insist on
An assurance product that overstates its own scope has failed at the thing it exists to do. StackAttest tests software directly. It does not assess an organization.
That means it complements an audit such as SOC 2 rather than replacing one. SOC 2 examines organizational controls over time. StackAttest examines the software. Both are useful and they answer different questions, and conflating them would be dishonest in a way that is commercially tempting and technically indefensible.
Kept separate on purpose. A single blended number would hide the difference between a strong result on thorough evidence and a strong result on very little.
This shaped how we write. It is why case studies on this site link to sources you can check and why we label estimates as estimates rather than presenting them as measurements.
A clean result from a shallow check is not reassurance. We now report what an audit did not examine alongside what it found, because the gap is where the risk sits.
Building a system where model output is deliberately prevented from moving a computed number is the clearest version of a principle we apply to every AI system we build for clients.
Teams review the code they wrote and rarely the several hundred packages underneath it. That imbalance shows up constantly in real assessments.
Access control, recovery, observability and dependency health decide whether software survives contact with production. A green pipeline says the tests passed, not that the system is ready.
Our own security product holds one. It is the clearest way to see what the output actually looks like, including the levels not yet reached, which is the part a marketing page would omit.
View the SecAI Passport (opens in a new tab)If you are trying to establish whether a system is genuinely ready, or build one that could withstand that question, tell us what you are working with.