SOC 2 / pentest
- Looked at access, change, CVEs
- Void after settle not in scope
Topic · Business logic
We do SOC2 and pentests but nothing verifies the business logic is right. What fills that gap?
Gist
A Type II letter asks whether the control ran. A pentest asks whether a stranger can reach the void button. Proof fails the merge when a signed shall has no witness, with the same command on every push.
proof audit --fail-level warnKeep the auditor. Keep the pentest firm. Snyk still scans. None of them re-read the invoice rule you sold.
01 · The letter
SOC 2 does not know what you sold.
The report can be clean while a paid invoice is still voidable after settlement. That is not a missed control. It is a missed obligation.
The security-audit miss lives on passed a security audit, still shipping bugs. That page is CVE-clean code that still captures twice. The money path lives on fintech transaction logic. This page is the buyer who already pays for SOC 2 and a pentest, and still cannot point at a check for the rule sales quoted.
SOC 2 asks whether access is logged, whether change management ran, whether the void is restricted to a role. A pentest asks whether that role can be skipped. The sold rule was: after settlement, a paid invoice cannot be voided. Nobody in those two PDFs compiled that sentence.
func VoidInvoice(paid, settled bool) error {
if !paid {
return errUnpaid
}
return nil
}
The helper refuses unpaid invoices. Tests at unpaid and paid-not-settled pass. The Type II letter is still true. The pentest still cannot void without a session. Settlement was never a condition. proof audit --fail-level warn fails when that shall has no witness on this branch.
02 · The exhibit
Same invoice. A letter, or a shall.
The letter is last quarter. The shall is this push. Click the tabs.
The shall
After settlement, a paid invoice cannot be voided. Not a control. Not a CVE.
Not in the letterSOC 2 / pentest
Still last quarter. Still a PDF. Still no settlement condition.
Still the letterProof
- Ask does this branch witness no-void-after-settle
- Gate audit --fail-level warn
Same invoice. A letter, or a shall. Click the tabs.
| Who | What they notice | What they lose |
|---|---|---|
| SOC 2 Type II | Whether the named controls ran in the window | The letter is last quarter. Settlement was not a control. |
| The pentest firm | Whether a stranger can reach void without a role | Auth is not the sold rule. Keep Cobalt. That split lives on correctness vs security. |
| Snyk / the scanner | CVEs and known bad patterns in the tree | A void after settle is not a CVE. That incumbent lives on Proof vs Snyk. |
| Proof | The shall still has a witness, or the merge stays red | Proof does not write the Type II letter. Jama still authors the programme. |
We have not run Proof against a SOC 2 Type II letter and a pentest PDF on a frozen corpus of invoice code. The loss is named, not scored. Keep the auditor. Keep the pentest. Neither is the merge gate for an approved shall, and neither re-runs when the helper changes tonight.
03 · The honest loss
A red Proof audit is not a SOC 2 report.
If nobody signed “no void after settlement,” there is nothing for proof audit --fail-level warn to fail on except the suite you already have.
Proof is not a SOC 2 auditor. It is not PCI. It is not a pentest firm. Kind2 is not TLA+ for sagas. FRETish is 288 templates, not free English. Jama still wins at programme authoring. 100% MC/DC on the written decision still misses a partition that was never a condition. That instrument stays on MC/DC for Go.
The independent check that does not name SOC 2 lives on software correctness audit. The money-path H1 lives on fintech transaction logic. The CVE-clean miss lives on correctness vs security.
04 · Nearby questions
What people type next.
We passed a security audit but still ship functional bugs. What kind of audit catches those? The CVE-clean miss. Correctness vs security.
Penetration testing checks if we can be hacked. What checks if the software actually works correctly? FAQ on that same URL. Keep Cobalt.
We're a fintech and need proof our transaction logic is correct. What are our options? The money path. Fintech transaction logic.
What kind of firm reviews whether software is correct, not just secure? The install is the audit. Do not mint a twin.