Security audit

What this audit answers

The security audit asks which concrete security weaknesses are visible in the checked repository revision and how urgently they should be addressed. It looks for evidence an attacker could plausibly use: exposed secrets, unsafe authentication or authorization, injection paths, insecure defaults, risky file or network handling, supply-chain execution paths, and other repository-backed weaknesses.

It is not a penetration test and does not claim that the absence of a finding proves the system secure. The answer is bounded by the source, configuration, history depth, tool coverage, and optional passive website evidence available to the run.

What Guard inspects

Guard maps languages, frameworks, manifests, lockfiles, entry points, trust boundaries, authentication and authorization paths, data stores, external integrations, CI workflows, deployment configuration, and security-sensitive code. It may use static scanners and ecosystem-aware read-only tools when they can run safely. Results are normalized and deduplicated so one root cause is not counted repeatedly as separate symptoms.

If a website is explicitly in scope, the audit may perform tightly bounded passive checks. It does not fuzz endpoints, bypass controls, exploit a suspected weakness, enumerate private data, or run repository code just to make a scanner work.

How evidence becomes findings

Every scored finding needs repository or passive evidence, a confidence level, a root cause, an impact, and a practical recommendation. Guard separates confirmed facts from plausible but unverified signals. Low-confidence observations and missing tool coverage belong in limitations instead of being promoted into score-reducing findings.

Secrets are redacted in reports. A finding should identify the affected path or configuration without reproducing a credential. Dependency facts are included here only when they create a security exposure within the audit boundary; broader freshness and reproducibility belong to the Dependency hygiene audit.

How the score works

The score starts at 100 and counts unique root causes with medium-or-higher confidence:

score = 100 - critical×45 - high×16 - medium×6 - low×2

If at least one critical finding exists, the final score is capped at 39. The result is then clamped to 0–100 and shown in the shared green, yellow, or red zone. An ordinary missing pin or floating dependency does not automatically become critical; the critical cap requires evidence of a genuinely dangerous condition, such as a privileged package-acquisition path that can execute fresh public code.

The formula keeps a critical weakness from being averaged away by many healthy areas. Open the findings rather than using the score as an approval decision.

Limitations and boundaries

The audit is read-only. It does not install and execute the target application, run untrusted repository scripts, perform active exploitation, or change provider settings. Static evidence can miss runtime-only behavior, externally managed controls, private infrastructure, and weaknesses outside the captured revision. Those gaps must be stated with their practical effect on confidence.

The report is engineering evidence, not a compliance certification or a guarantee against compromise.

Improvements and reruns

Start with critical and high-confidence root causes that have a bounded remediation path. A security improvement may create an issue when owner judgment is required or a reviewable branch and pull request when the change can be made safely. High-blast-radius authentication, authorization, infrastructure, or package-acquisition changes should remain human-controlled.

After the change is merged, rerun the security audit against the resulting commit. The rerun should show whether the original evidence disappeared, whether verification succeeded, and whether the change introduced a different security condition.