Technical evaluation / 2026-09-22

Start with a record.
Make the fit testable.

A dated configuration baseline, the inputs for a useful evaluation, and one product result you can inspect and repeat.

Three kinds of evidence, kept separate.

Source-reviewed configuration describes what the recorded implementation admits. The local run demonstrates a small deterministic workflow. Model quality, deployment acceptance and customer workload performance still require their own measurements.

01 / Source-reviewed configuration

Name the version.
Then check the environment.

This record was reviewed on 2026-09-22 against product source 9174a1c9bfbe7147bb59d88ce1d2ea89f1807bc7. Referenced files were compared byte-for-byte with that commit. It identifies a source baseline; it does not identify the release in every customer installation.

Download the source record
Source reviewed · no live acceptance claim

Application host / external gateway profile

Single-node RHEL 9 on linux/amd64; rootful Docker Engine and Compose v2, cgroup v2 and systemd. The documented profile uses SELinux enforcing and firewalld.

This source baseline does not establish HA, Podman/Quadlet, or acceptance of other Enterprise Linux distributions.

Source reviewed · no live acceptance claim

Default application allocation

The shipped service limits call for 8 logical CPUs, approximately 22 GB host memory, and 100 GiB free data space. Inode capacity and storage checks also apply.

These are provisioning inputs for the documented defaults, not measured throughput or a universal minimum. Changed container limits require a new host check. Model-serving hardware is separate.

Source reviewed · no live acceptance claim

External inference policy

For this on-premises external-gateway policy, the admitted pairs are gpt-oss-120b → openai/gpt-oss-120b and minimax-m2.7 → MiniMaxAI/MiniMax-M2.7.

This lists exact configuration admission at the recorded source revision. It is not the full catalogue of TraceMint model bundles, a live model acceptance test, or evidence of model quality.

Source reviewed · no live acceptance claim

Gateway connection

An OpenAI-compatible HTTPS endpoint, a protected token file and a dedicated CA bundle are required by this profile. Request settings and model identity are checked; alternate fallback credentials are rejected.

A compatible protocol name alone does not qualify every provider. Record endpoint operator, region, retention, model revision, context and concurrency before enabling inference.

Current native source-file registry · 12 languages

These extensions describe file admission, not equal model quality. Language selection, file limits and exclusions still determine the actual scan scope. In a mixed repository, a language represented by one file can need explicit selection.

JavaScript.js, .jsx, .mjs
TypeScript.ts, .tsx
Python.py, .pyx
Java.java, .jelly, .jsp
C#.cs, .cshtml, .razor
PHP.php
Ruby.rb
Go.go
Rust.rs
C.c, .h
C++.cpp, .cc, .cxx, .hpp
Swift.swift

C# coverage does not imply every .NET language. Infrastructure configuration rules are a separate workflow. Review source-language scope.

Inference hardware needs its own acceptance record.

No measured GPU sizing or AI throughput table is included in this pack. Record the exact model weights, quantization, runtime, context window, concurrency and workload before selecting inference capacity. The example below used no model or GPU.

02 / Connection preparation

Give each credential
a specific job.

These recipes reflect the recorded TraceMint setup paths. Confirm the provider edition, account scope and enabled action during setup; a repository connection does not turn on every feedback or upload workflow.

01

GitHub App / repository automation

Metadata: read; Contents: read. Pull requests and Checks: read/write for the corresponding feedback workflows.

Limit the installation to selected repositories. Validate push/pull_request events, then the exact comment or check-run handoff you enable.

02

GitHub Actions / SARIF upload

contents: read; security-events: write; actions: read. Add pull-requests: write only when the workflow posts PR comments.

This workflow token serves a different purpose from the GitHub App credentials. Retain the workflow run, SARIF digest and upload receipt.

03

GitLab / configured onboarding

The recorded setup requests api, read_user and read_repository scopes. api grants broad API access: scope the account and project deliberately.

Confirm the GitLab edition, URL, selected project and requested automation. Test repository import, webhook delivery and MR feedback separately.

Provider requirements can change. Validate credentials through the installed connection test and use its least-privilege settings. Compare SCM setup paths.

Bring an export you can trace to source.

The pack includes a minimal SARIF 2.1.0 file and generic CSV with explicit columns. Both were parsed by the product importer. They are authored examples, not evidence that every Checkmarx, Fortify or other vendor version is compatible. Bring a native export from your exact scanner edition and a matching source revision; preserve the source-match and unresolved counts.

03 / Actual product run · deterministic configuration checks

Two files in.
One rule finding out.

The real TraceMint local configuration-rule function read two newly authored CC0 Dockerfiles. The resulting finding below comes from its recorded output. The files were never built or executed; no AI model, running application or customer repository was involved.

2Dockerfiles read
1Rule finding
0Network attempts
0Model calls

risk.Dockerfile

1 matching rule
# SPDX-License-Identifier: CC0-1.0
FROM scratch
USER root

dockerfile_root_user · line 3 · severity: high

The product recommends using an unprivileged user in the final image stage. This is a source-configuration observation, not a reproduced exploit.

Download this input

control.Dockerfile

0 matching rules
# SPDX-License-Identifier: CC0-1.0
FROM scratch
USER 10001

A non-root USER provides the comparison.

No matching rule in this tiny file does not establish a secure image. These files are inspection fixtures and contain no runnable application.

Download this input
Recorded
Product implementation
services.supply_chain_posture._scan_local_container_iac
Source identity
18 imported product modules matched the recorded commit; SHA-256 hashes are included.
Runtime
Python 3.11.13 · Darwin 24.3.0 / arm64 · PyYAML 6.0.3 · defusedxml 0.7.1
Observed function time
0.66 ms for the configuration check; 0.91 ms for the two parser calls.
Timing boundary
One invocation per check. Excludes process startup, imports, provenance verification and file writing. This is a run record, not a throughput benchmark.
Import observations
1 authored SARIF row and 1 authored generic CSV row normalized. Both retained src/fixture.py, line 4. No source enrichment or AI triage ran.
A bounded result you can examine.

The JSON retains the actual rule output, inventory, input hashes, source hashes and runtime. The Python runner rejects a product source mismatch and blocks network calls in its process. Reproduction requires a separately licensed matching product checkout; no product implementation is redistributed.

Read the full machine record
04 / Take it into your evaluation

Keep the inputs.
Record what remains unknown.

Use the worksheet to agree the release, data boundary, inputs, reviewers and acceptance criteria. Record observed results separately from assumptions. The configuration example does not supply AI precision, recall, model performance or installation acceptance.

The ZIP also contains reproduction instructions and both Dockerfiles. Read the instructions. Fixture CC0 applies only to the authored inputs, not the product or models.

Plan your evaluation

Bring one representative workflow.

Share the scanner edition, repository layout and deployment constraints you want to validate. Keep credentials, code and sensitive reports out of the contact form.

Discuss the evaluation