Skip to main content
This page outlines the internal audit process for Cosmos Stack components.

​
Overview

Cosmos Labs runs a structured internal audit on complex features before they ship, in addition to any external audits. The goal is to verify correctness, security, and maintainability through a collaborative, line-by-line review led by the engineers with the most context on the code. The process has two stages:
  1. Pre-audit report
  2. Internal audit
Each audit is run by a designated audit lead, normally the person with the deepest context on the feature under review. The lead prepares the materials, briefs the team, facilitates the review, and splits the audit across multiple sessions when the feature is large.

​
Stage 1: Pre-audit report

The pre-audit report is a prerequisite to the internal audit. It is a macro-level review that surfaces systemic and integration risks early, before the full team is brought in. Critical issues found here must be resolved before the internal audit is scheduled. The audit lead produces a pre-audit document covering:
  • Scope definition: every file added or modified, with attention to those that introduce or depend on integration points.
  • Critical integration point analysis: changes in related or dependent modules outside the core feature that could introduce integration failures.
  • Spec diff: updates to the feature specification, compared against the current implementation.
  • Problem-first search: known problem areas and likely failure cases specific to the feature.
Objectives of this stage:
  • Review code changes since the last stable milestone.
  • Detect integration issues across system boundaries.
  • Proactively investigate known vulnerability patterns and risk vectors, including state corruption, authorization failures, replay or race conditions, data consistency issues, resource exhaustion, callback or reentrancy risks, and other feature-specific failure modes.
  • Evaluate the risk introduced by untrusted or novel external dependencies.

​
Stage 2: Internal audit

Once the pre-audit report is complete and any critical issues are addressed, the audit lead schedules the internal audit: a live, line-by-line code review with the full team. The session is interactive. Participants ask questions, clarify assumptions, and flag concerns while the lead provides context on design intent and technical decisions. Large or complex features are split across multiple sessions by subsystem.

​
Context briefing

The lead opens the audit by providing the context needed to review the feature:
  • A summary of the feature and its intended behavior.
  • Key design decisions and tradeoffs.
  • Integration risks identified during the pre-audit.
  • Diagrams and visuals for complex workflows.
Context briefings are recorded so they can be preserved as a reusable knowledge base. A briefing is skipped when an existing recording already covers the same ground.

​
Line-by-line review

The review starts at user entry points and follows the flow of logic, with attention to:
  • Correctness of implementation and internal function logic.
  • Input validation.
  • Authentication, authorization, and access control.
  • State consistency and post-conditions.
  • Performance, resource usage, storage layout, and efficiency.
  • Error handling and logging.
  • Adherence to the specification and intended semantics.
  • Event emission and observability.
  • Test coverage, edge cases, and failure-path validation.
  • Code readability and maintainability.
  • Use of external libraries and dependencies.
Security-critical external code that is not heavily battle-tested receives extra scrutiny. This includes parsing, serialization, cryptography, verification logic, and other security-sensitive components, where past audits have uncovered bugs in upstream dependencies.

​
Audit outcomes

Throughout the audit, designated team members document every issue, concern, and open question. These notes are formalized into tracked issues and follow-up tasks scheduled in upcoming engineering iterations. Each item is categorized to support prioritization and triage after the audit, for example as a bug, optimization, specification mismatch, documentation improvement, or investigation needed.