Security

Real offensive depth

Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.

All security →
Compliance

Audit-ready, fixed scope

SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.

All frameworks →
Resources

Learn the space

Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.

Read the blog →
Security & Compliance Glossary

SAST (Static Application Security Testing)

SAST, or Static Application Security Testing, analyzes an application's source code, bytecode, or binaries for security flaws without running the program. It is a white-box technique that inspects code from the inside to catch issues like injection flaws and insecure patterns early. SAST runs in the development pipeline before code is deployed.

In practice

SAST shifts security left: it flags vulnerable code as developers write it, often inside the IDE or on every pull request, where fixes are cheapest. It can pinpoint the exact file and line.

Because it reasons about code paths it cannot always execute, SAST is prone to false positives and cannot find runtime or configuration issues. It pairs with DAST, which tests the running application from the outside.

// how traztech helps

traztech delivers a vulnerability management programme for startups and growth-stage companies, led by a published security researcher.

Book a call

For a broader look at getting audit-ready, see our SOC 2 readiness work, or talk to a fractional CISO about building a program around it.

Where it comes up

SAST tends to arrive in a compliance programme as a control about secure development. The auditor is not asking whether you own a scanner; they are asking whether findings are triaged and whether anything blocks a release.

The failure mode is noise. A SAST tool switched on across a large codebase produces thousands of findings, the team learns to ignore the dashboard, and the control exists on paper only.

SAST (Static Application Security Testing): common questions

Does SAST satisfy a secure development control?

Partly. Tooling alone does not. What evidences the control is the process around it: triage, ownership, remediation timelines and evidence that they were met.

SAST or DAST first?

SAST is usually easier to introduce because it runs in the pipeline without a deployed environment. DAST catches a different class of issue and most mature programmes end up running both.

Track record

Who is actually doing the work

5
Published CVEs, including a CVSS 9.1
76
Controls taken from nothing to a passed SOC 2 Type II
Zero
Exceptions on that Type II report
20+
Penetration testing engagements delivered

Published vulnerability research

Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.

A SOC 2 Type II built from nothing

At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.

Before you go

Want the practical version by email?

Definitions only get you so far. I send a few short notes on how this plays out in practice. Unsubscribe in one click, and replies reach me directly.

From Jacob Masse, principal of traztech. No spam, unsubscribe in one click.