Audit methodology and evidence standards
How BSA is designed to work, and the standard of evidence its results are meant to meet.
BSA is in development. This page describes the methodology the platform is being built to follow. It is not a report of completed audits.
Authorization comes first
Active testing is designed to run only inside a recorded authorization. The record names the owner, the scope (domains, repositories, hosts), the allowed test classes, the time window and the approver, and keeps a hash of the authorization document.
Without an authorization record, only passive checks run: public pages, headers, TLS, DNS and structured data, with robots.txt respected. Third-party targets receive passive checks only.
Independent of what it audits
BSA is designed to have no runtime dependency on any product it audits. A product's own report about its security is a declaration. It is not evidence, and BSA does not treat it as proof.
Evidence standard
Nothing is marked passed or verified without stored evidence. When there is no evidence, the answer is "not yet verified", "not audited" or "could not verify". It is never "passed".
- Each finding is meant to carry its evidence, a confidence level and a severity.
- Confirmed findings are kept apart from likely or potential ones.
- A missing test is reported as unverified. It is never reported as a broken feature, and a broken feature is never reported as merely untested.
Finding statuses
- Identified: a condition was found and still needs confirming.
- Tested: a check was run and its result and evidence were stored.
- Verified: stored evidence supports the result.
- Not yet verified: there is no evidence either way.
Retesting
A finding is closed by passing a retest of the original check. Changing a status alone does not close a finding. Fixed findings that return are tracked as regressions.
Safety
- Testing is non-destructive by default.
- No destructive tests are run against production by default.
- Fixes are never applied to production automatically. Recommendations are for the owner to review and apply.
Compliance mapping
BSA is designed to separate technical evidence, documented policy, operational evidence and external certification. Mapping technical evidence to a control framework supports an assessment. It does not confer certification and is not legal advice.
What this site does not claim
BSA does not guarantee that any system is secure or compliant, and this site does not claim completed audits, certifications, customers or integrations.