Code security scanning,
filed against the control it breaks.

• Runs in your CI, a pre-push hook or locally; nothing leaves your environment except results
• Built-in static rules with file and line, plus Semgrep and Trivy when they are installed
• Dependency audit for JavaScript and TypeScript projects; other ecosystems through Trivy
• IaC checks per resource: Terraform, CloudFormation, Kubernetes, Docker Compose, Dockerfiles and CI workflows
• Behaviour checks for Express, Fastify, NestJS and Next.js: authentication per route, rate limiting, input validation
• Sign-in checks: JWT algorithm and lifetime, MFA, lockout and password policy
• Every push recorded with commit, branch and author

Code security scanning for compliance means running static analysis, dependency and secret scanning on every change and keeping the results as evidence for the controls that ask for secure development. SOC 2 CC8.1, ISO 27001 Annex A 8.25 to 8.29 and DPDP's reasonable security safeguards all expect it to happen continuously, not once before an audit.

The difference from a standalone scanner is where the finding goes. A scanner hands you a list sorted by severity. Here each finding is a control result, so a hardcoded secret fails the access-control control in every framework you run and shows on the readiness score the same hour.

1. Install the SDK in the pipelineAdd the SDK to your repository and run trytrustable sync from CI, a pre-push hook or a developer's machine. The developer docs include a generated CI workflow, so the first run needs no hand-written YAML.
2. Static rules run firstThe SDK's own rules read the code and report each match with the file and line. They cover patterns such as hardcoded credentials, weak cryptography and unsafe request handling, and they run with no other tool installed.
3. Semgrep and Trivy join if presentWhen Semgrep is on the runner it runs with --config auto; when Trivy is present it scans the file system for vulnerable dependencies, misconfiguration and secrets. If either is missing, its checks are recorded as skipped, with the reason, and never as passed.
4. Control checks read behaviour, not just textAbout 80 control checks look at how the application is put together: whether each Express, Fastify, NestJS or Next.js route requires authentication, whether rate limiting and input validation are in place, how JWTs are signed and how long they live, and whether MFA, lockout and password rules exist.
5. Results become control resultsEach finding is sent with its check, status, file, line and the control it relates to, and the push is recorded with commit, branch and author. The same result then counts in every framework that maps to that control.
6. Exceptions stay visibleA finding can be accepted only with an inline comment that names the check and gives a reason of at least ten characters. It is then reported as a justified exception, which a reviewer sees in the diff and an auditor sees in the evidence.

Because a scanner that is not installed, times out or crashes usually exits cleanly, and a clean exit read as a pass is the most flattering wrong answer a pipeline can give. When Semgrep or Trivy is missing, the SDK records the check as skipped and says so; it never writes a pass for a test that did not run.

Suppressions follow the same rule. A finding can be accepted only with an inline comment that names the check and gives a reason, so every exception is visible in the code review and in the evidence.

The built-in rules and behaviour checks are strongest on JavaScript and TypeScript, including the Express, Fastify, NestJS and Next.js route checks. Other languages are covered through Semgrep and Trivy when they are installed in the pipeline. Infrastructure-as-code checks are language-independent.

SAST reads your own source code for unsafe patterns, SCA checks the open-source packages you depend on against known vulnerabilities, IaC scanning checks infrastructure definitions for insecure settings, and secret scanning looks for credentials committed to the repository. Each finds a different class of problem, and a security programme that an auditor accepts usually needs all four.

SAST (static application security testing) catches the mistakes your team writes: a SQL query built from a string, a hardcoded API key, a weak hash. SCA (software composition analysis) catches the mistakes other people wrote that you shipped: most of a modern JavaScript application is dependencies, so a single vulnerable package can matter more than your own code. IaC scanning catches an S3 bucket left public or a Kubernetes pod running as root before it is deployed. Secret scanning catches the credential that should never have been committed, which is often the shortest path into production.

None of them proves an application is secure. They prove that known classes of weakness are looked for on every change, which is what SOC 2 CC8.1 and ISO 27001 A.8.25 to A.8.29 actually ask.

Because the most common serious finding in a web application is a route that should require sign-in and does not, and a pattern-matching rule cannot see that. The SDK reads the route table of Express, Fastify, NestJS and Next.js applications and reports which routes have authentication, rate limiting and input validation, and which do not.

That turns an auditor's question, "how do you know every endpoint is protected?", into a list with a date on it. It also catches the regression that code review misses: a new endpoint added in a hurry, outside the middleware that protects the rest.

The same approach applies to sign-in. The checks read how JWTs are signed and how long they last, whether MFA exists, whether accounts lock after repeated failures and what the password rules are, so the access control evidence comes from the code that enforces it rather than from a policy document.

An exception should name the finding, give a reason, and be visible to a reviewer; an exception that does none of these is a permanent hole that looks the same as a fix. In TryTrustable an exception is an inline comment, // trytrustable-ignore <check-id>: <reason>, and a reason shorter than ten characters is rejected.

Putting the exception in the code, next to the line it excuses, means it goes through the same pull request review as any other change. The reviewer sees who added it and why. The evidence then records the finding as a justified exception, so the auditor sees an accepted risk with a reason, not a silent pass.

Review exceptions on a schedule. A reason that was true when a dependency had no fix may stop being true when the fix ships; the record of when each exception was added is what makes that review possible.

The SDK runs anywhere Node.js runs, so it works in GitHub Actions, GitLab CI and any other CI that can run a command, as well as in a pre-push hook or on a laptop. The built-in rules, dependency audit and route checks are strongest on JavaScript and TypeScript.

For other languages, coverage comes from Semgrep and Trivy when they are installed on the runner. IaC checks do not depend on the application language. If your stack is mostly Go, Java or Python, install Semgrep and Trivy in the pipeline so the scan is not limited to infrastructure and secrets.

• Your secure development policy, and evidence that it was followed for changes sampled from the audit period
• Scan results for specific commits or releases the auditor picks, with dates
• Proof that a failing scan blocks a merge, usually the branch protection setting plus an example of a blocked pull request
• Every exception granted during the period, with who granted it and why
• How a skipped or failed scanner is detected, so a broken tool does not read as a clean result
• How dependency vulnerabilities found by the scan were tracked to remediation

• It does not send your source code to TryTrustable; only results leave the pipeline
• It does not test a running application; that is web security testing
• It does not fix code or open pull requests for you
• Its built-in rules are strongest on JavaScript and TypeScript; other languages rely on Semgrep and Trivy being installed
• It does not replace code review or a penetration test by a human tester

Every result here is a control result on the same graph as the rest of the platform, so it reaches each framework that asks for it without being gathered again. Coverage lists the regimes.

Related reading: compliance as code in CI, the SDK and CI gate and vulnerability management.