01
Trace trust decisions
Review where the application accepts identity, authority, external input, data ownership and service-to-service trust.
Damocles application security
Find security defects before they become production incidents.
Damocles Secure Code Review follows identities, data and privileged actions through the implementation to find design and business-logic defects automated tools often miss.
Architecture and trust boundariesAuthentication and authorisationBusiness logic and data flowDeveloper-ready remediation
The customer problem
The most serious application defects often come from a trusted assumption that the code never enforces.
An application can pass dependency and syntax checks while still allowing one customer to access another customer’s data, a lower-privileged user to call an administrative function, a workflow to be repeated out of sequence or a secret to be exposed through logging and error handling.
The review traces the code paths that protect sensitive data and privileged operations, then gives developers precise evidence and implementation-focused remediation rather than generic secure-coding advice.
02
Find business-logic abuse
Identify unsafe sequences, limit bypass, duplicate actions, role confusion and state transitions that tools do not understand.
03
Make remediation implementable
Reference affected code, explain the abuse case and discuss the design or implementation change with the engineering team.
Service coverage
Review the code and design controls that protect sensitive operations.
The review is tailored to the language, framework, architecture, repository size, release risk and available test environment.
AR
Architecture and trust boundaries
Service boundaries, data flows, external dependencies, privilege transitions and assumptions between components.
AU
Authentication and sessions
Login, MFA integration, tokens, session lifecycle, recovery, impersonation and logout behaviour.
AZ
Authorisation and tenancy
Role checks, object ownership, tenant separation, privileged functions and server-side enforcement.
BL
Business logic
Workflow sequence, limits, replay, duplicate operations, approvals, state changes and abuse of intended features.
DH
Data and input handling
Validation, encoding, injection paths, file handling, deserialisation, output handling and sensitive-data exposure.
SC
Secrets, cryptography and logging
Secret storage, key use, encryption, signatures, hashing, error handling, audit records and unsafe diagnostic output.
Technical assurance
Find security weaknesses in the code paths that matter.
Review architecture and source code to trace trust boundaries, sensitive data and security-critical functions that runtime testing may not fully expose.
Architecture and trust
Entry points, components, identities and data flows.
Authentication and authorisation
Implementation of identity, roles and access decisions.
Input and output
Validation, injection, parsing and encoding weaknesses.
Secrets and cryptography
Credential handling, key use and security-sensitive algorithms.
Data protection
Sensitive-data storage, logging and lifecycle decisions.
Dependencies
Third-party component use and unsafe integration patterns.
Error and concurrency handling
Failure paths, race conditions and unsafe state changes.
Security observability
Events and context available for investigation and audit.
What we actually test
Jump to full coverage matrix ↓Representative technical coverage with the evidence produced.
These are governed procedures from the service assurance profile—not generic marketing categories. The complete matrix below records applicability, access requirements and limitations for every coverage area.
Repositories, branches and commits
Damocles fixes the review boundary to named repositories, branches and commits and records generated, vendored and excluded content.
Architecture and trust boundaries
Damocles traces trust boundaries and data flows from architecture evidence into the files, modules and calls that implement them.
Authentication implementation
Damocles follows credential verification, MFA, recovery and session creation through the responsible functions and configuration paths.
Authorisation enforcement
Damocles traces role, object and tenant checks from entry points to data access and identifies missing or client-only enforcement.
Input validation
Damocles follows untrusted data through parsing, validation, canonicalisation and interpreter or query sinks.
Output encoding
Damocles traces untrusted values to HTML, URL, command, document or other output contexts and reviews the selected encoding routines.
Showing 6 representative areas. The full governed matrix contains 15 coverage areas.
Standards and assurance coverage
See how this engagement is structured, classified and mapped before opening the full evidence matrix.
References are shown according to the role they play in the engagement. Methodologies guide testing, taxonomies classify findings, severity methods support consistent scoring, and control mappings connect scoped evidence to broader assurance work.
How testing is structured
Approved methodology, verification and testing guidance used to select and structure relevant procedures within the authorised scope.
How weaknesses and severity are classified
Approved risk, weakness and severity references provide a consistent language for confirmed findings without replacing customer-specific business impact.
What maps into compliance and assurance work
1governed evidence mapping across 1 approved framework, with framework-level context where exact controls are not claimed.
1 contextual
Security and Privacy Controls for Information Systems and Organizations Release 5.2.0Contextual
Framework-level context
The engagement produces point-in-time technical evidence about the configured and observed security behaviour within the authorised Secure code review scope.
What the customer can use after the engagement
A code-referenced report with affected files or functions, practical impact, remediation guidance and validation results.
- Authorised scope and rules of engagement
- Coverage matrix
- Retest and residual-risk record
- + 3 additional controlled outputs
What this means: technical evidence may support risk, compliance and audit activity where the mapping is applicable. It does not by itself certify the organisation, establish complete compliance or assess controls outside the authorised scope.
Manual validation backed by controlled evidence.
Damocles traces security decisions through the named repositories, branches, files, functions and data flows, recording exact code locations and design assumptions. Runtime confirmation is performed only when separately included; generated code and excluded dependencies are not represented as reviewed.
Evidence is mapped to the part of a control we can actually assess.
Directly assessed means the engagement tests the relevant behaviour. Supporting evidence means the result can contribute to a broader control assessment. Contextual references explain relevance without claiming that the control was tested.
All relevant frameworks
Application Security Verification Standard 5.0.0Common Weakness Enumeration 4.20Guidelines for Software Development June 2026Security and Privacy Controls for Information Systems and Organizations Release 5.2.0
Testing perspectives3 authorised viewpoints and access models
Source-code reviewer
Traces security-relevant data and control flow through named files, functions, classes and modules.
Architecture and repository reviewer
Reconciles repository boundaries and implementation with diagrams, trust assumptions, generated code and dependency ownership.
Runtime-assisted reviewer where separately included
Executes narrowly scoped runtime checks to confirm selected source-level hypotheses.
Exact test coverage and evidence15 governed coverage areas
| Coverage area | What Damocles tests | Perspective and access | Evidence produced | References and limits |
|---|---|---|---|---|
| Repositories, branches and commits | Damocles fixes the review boundary to named repositories, branches and commits and records generated, vendored and excluded content. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for repositories, branches and commits. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to repositories, branches and commits. | Application Security Verification Standard 5.0.0 Applicability: Applies to Repositories, branches and commits when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled repositories, branches and commits; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Architecture and trust boundaries | Damocles traces trust boundaries and data flows from architecture evidence into the files, modules and calls that implement them. | Architecture and repository reviewer, Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for architecture and trust boundaries. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to architecture and trust boundaries. | Application Security Verification Standard 5.0.0 Applicability: Applies to Architecture and trust boundaries when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled architecture and trust boundaries; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Authentication implementation | Damocles follows credential verification, MFA, recovery and session creation through the responsible functions and configuration paths. | Architecture and repository reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for authentication implementation. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to authentication implementation. | Application Security Verification Standard 5.0.0 Applicability: Applies to Authentication implementation when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled authentication implementation; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Authorisation enforcement | Damocles traces role, object and tenant checks from entry points to data access and identifies missing or client-only enforcement. | Architecture and repository reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for authorisation enforcement. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to authorisation enforcement. | Application Security Verification Standard 5.0.0 Applicability: Applies to Authorisation enforcement when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled authorisation enforcement; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Input validation | Damocles follows untrusted data through parsing, validation, canonicalisation and interpreter or query sinks. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for input validation. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to input validation. | Application Security Verification Standard 5.0.0 Applicability: Applies to Input validation when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled input validation; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Output encoding | Damocles traces untrusted values to HTML, URL, command, document or other output contexts and reviews the selected encoding routines. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for output encoding. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to output encoding. | Application Security Verification Standard 5.0.0 Applicability: Applies to Output encoding when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled output encoding; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Cryptographic use | Damocles reviews cryptographic algorithms, modes, randomness, key derivation, key custody and call-site error handling in source. | Source-code reviewer Current configuration export or read-only access, diagrams, owners and representative validation endpoints. | Evidence cites the repository, commit, file, function and cryptographic API call or unsafe source-code logic. | Application Security Verification Standard 5.0.0 Applicability: Performed when current configuration evidence and a representative endpoint or device are included in the review. Limit: A configuration snapshot cannot prove continuous enforcement across excluded nodes; validation avoids changes unless implementation work is authorised. |
| Secrets handling | Damocles searches authorised source and configuration for embedded secrets and traces secret loading, use, rotation and logging paths. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for secrets handling. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to secrets handling. | Application Security Verification Standard 5.0.0 Applicability: Applies to Secrets handling when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled secrets handling; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Dependency use | Damocles reviews dependency manifests, lockfiles and security-sensitive library use and distinguishes direct code defects from dependency risk. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for dependency use. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to dependency use. | Application Security Verification Standard 5.0.0 Applicability: Applies to Dependency use when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled dependency use; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Error handling | Damocles follows exceptional paths to determine whether failures expose sensitive detail, bypass cleanup or create unsafe default behaviour. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for error handling. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to error handling. | Application Security Verification Standard 5.0.0 Applicability: Applies to Error handling when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled error handling; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Security logging | Damocles traces security event creation, sensitive-field filtering, correlation identifiers and audit integrity through logging calls. | Runtime-assisted reviewer where separately included Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for security logging. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to security logging. | Application Security Verification Standard 5.0.0 Applicability: Applies to Security logging when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled security logging; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Concurrency and state | Damocles examines shared state, locking, transactions, ordering and retry code for races, duplicate processing and inconsistent authorisation. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for concurrency and state. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to concurrency and state. | Application Security Verification Standard 5.0.0 Applicability: Applies to Concurrency and state when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled concurrency and state; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Business logic | Damocles traces business prerequisites, state transitions, limits and approval decisions through the functions that enforce them. | Source-code reviewer Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for business logic. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to business logic. | Application Security Verification Standard 5.0.0 Applicability: Applies to Business logic when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled business logic; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Generated code and excluded dependencies | Damocles records generated code and excluded dependency boundaries and checks whether reviewed source safely invokes those opaque components. | Runtime-assisted reviewer where separately included Assessment requires named repositories, branches and commits, build context, architecture evidence and explicit exclusions, selected specifically for generated code and excluded dependencies. | Evidence records the repository, commit, file, function, class, module, data flow or call-path citation relevant to generated code and excluded dependencies. | Application Security Verification Standard 5.0.0 Applicability: Applies to Generated code and excluded dependencies when the implementing source is present in the agreed commit boundary. Limit: The conclusion is limited to the sampled generated code and excluded dependencies; source review cannot prove deployment or runtime behaviour unless separately validated. |
| Source review versus runtime validation | Damocles distinguishes conclusions supported by repository, file and function review from hypotheses requiring separately authorised runtime validation. | Runtime-assisted reviewer where separately included The exact repository and commit boundary plus a test deployment and accounts only when selected runtime hypotheses are separately authorised. | The finding cites the source-code location and marks runtime behaviour as observed, separately validated or not validated. | Application Security Verification Standard 5.0.0 Applicability: Applies to every source-review conclusion that depends on deployment state or behaviour unavailable in the reviewed code. Limit: Source evidence and runtime evidence are labelled separately; unexecuted code paths and excluded deployments remain unvalidated. |
Framework and control mappings1 governed evidence mappings
| Framework and controls | Mapping type | What Damocles assesses | Evidence produced | Applicability and limits |
|---|---|---|---|---|
| Security and Privacy Controls for Information Systems and Organizations Release 5.2.0 Framework-level context | Contextual | The engagement produces point-in-time technical evidence about the configured and observed security behaviour within the authorised Secure code review scope. | Coverage status, procedure results and findings can inform the customer’s control assessment and risk treatment records. | Applies: Framework-level context is provided when the customer uses NIST SP 800-53 to organise its security control program. Limit: No individual NIST control is published as verified; organisational implementation, continuous operation, governance and complete catalogue coverage remain outside the engagement. |
Assurance boundary: Damocles maps assessed coverage and observations to agreed objectives as traceable technical evidence. The review is not a certification, does not establish complete compliance, and does not confirm controls outside the authorised scope.
Report and evidence outputs6 controlled output types
Authorised scope and rules of engagement
Records authorised scope and rules of engagement produced from the authorised Secure code review work.
Coverage matrix
Records coverage matrix produced from the authorised Secure code review work.
Retest and residual-risk record
Records retest and residual-risk record produced from the authorised Secure code review work.
Repository and branch coverage
Records repository and branch coverage produced from the authorised Secure code review work.
File and code-location findings
Records file and code-location findings produced from the authorised Secure code review work.
Design and implementation trace
Records design and implementation trace produced from the authorised Secure code review work.
What you receive
A code-referenced report with affected files or functions, practical impact, remediation guidance and validation results.
Common engagement options
Match the review to the release risk and engineering question.
The statement of work identifies repositories, components, languages, commit or release boundaries, access, test environment and expected remediation support.
TR
High-risk component review
Review one identity, payment, administration, file-processing, integration or sensitive-data component in depth.
RR
Pre-release security review
Review the code and changed trust paths associated with a major release before production deployment.
BR
Application codebase review
Assess the architecture and highest-risk code paths across an agreed application or service set.
DF
Security design review
Assess trust boundaries, identity, data flows and control placement before or during implementation.
FR
Fix review
Review proposed or completed code changes for previously identified security defects.
WS
Developer remediation workshop
Walk through the findings, abuse cases, design options and implementation priorities with the engineering team.
Delivery lifecycle
Review the application in the context in which it is designed, built and operated.
Repository access, architecture, build instructions, deployment context, priority code paths and test data are agreed before the review begins.
01
Understand the system
Map identities, trust boundaries, sensitive data, privileged actions, integrations and critical business workflows.
02
Prioritise code paths
Select the components where failure would create the greatest customer, operational or security impact.
03
Trace implementation
Follow input, data, identity and authority through the relevant code and configuration.
04
Validate the defect
Confirm the abuse case with code evidence and an authorised environment where available.
05
Explain the fix
Document the affected code, exploit condition, impact and recommended design or implementation change.
06
Review remediation
Assess proposed or completed fixes and identify residual concerns where included.
What you receive
Findings written for developers, architects and the people approving the release.
The review should reduce ambiguity for the engineering team and make the release risk understandable to the customer’s decision-makers.
AO
Architecture observations
Trust boundaries, data flows, control placement and structural concerns affecting more than one code location.
CF
Code-level findings
Affected file or component context, unsafe logic, conditions, evidence, severity and impact.
AS
Abuse scenarios
Plain-language examples showing how a user, service or attacker could misuse the implementation.
RG
Remediation guidance
Specific design and implementation recommendations suited to the language and framework.
DW
Developer workshop
A practical walkthrough with the people responsible for the affected code and architecture.
FR
Fix-review record
A written assessment of the proposed or completed changes where remediation review is included.
What we need from the customer
The review needs enough code and context to understand how the application actually makes security decisions.
The customer provides repository access, the agreed branch or commit, build and test instructions, architecture or data-flow information, relevant configuration, dependency manifests, representative test data and access to engineering contacts.
A runnable environment is strongly preferred for validating material findings, but the review can still proceed against code and design evidence where execution is unavailable. Missing repositories, generated code, closed-source dependencies and inaccessible deployment configuration are documented as limitations.
What happens after delivery
The Secure Code Review engagement continues until the customer understands the work, the owners and the remaining risk.
The report or service record is the beginning of remediation, not the end of the engagement. These steps keep the outcome usable after formal delivery.
01
Confirm the material issues
Damocles walks the customer through the findings, evidence, affected scope, dependencies and uncertainty so there is agreement on what requires action.
02
Assign ownership
Each material recommendation is allocated to the team that can implement it, with a clear expected outcome and realistic dependency on other changes.
03
Sequence remediation
Quick risk reduction, structural change, compensating controls and longer-term engineering are separated so the customer can plan the work sensibly.
04
Capture implementation evidence
Configuration records, change references, screenshots, test results, source state or other agreed evidence are retained for later review.
05
Verify the result
Where included, Damocles reviews the changed state, performs a retest or reassessment, and records whether the original exposure is resolved, reduced or still present.
06
Record residual risk
Issues that cannot be fully removed remain visible with the accepted limitation, compensating control, review date and decision owner.
Commercial structure and change control
How a Secure Code Review engagement is scoped and kept commercially clear.
The proposal identifies the authorised scope, delivery method, assumptions, customer inputs, working window, deliverables, briefing, remediation support and any included retest or follow-up. Fixed-scope engagements are priced against that agreed boundary; retainers and managed services use the recurring quantity and service model stated in the schedule.
When the environment, target count, repositories, locations, access, service coverage or required evidence changes materially, Damocles records the impact before continuing. The customer can approve a variation, reduce the scope, defer the additional work or create a separate engagement. Hidden scope expansion is avoided because it produces poor testing and unreliable delivery dates.
Third-party licences, specialist platforms, travel, after-hours work, emergency response, remediation engineering and work outside the agreed deliverables are included only when listed in the proposal. Existing customer technologies can be used where they are supported and suitable; Damocles does not require a particular vendor simply to deliver the service.
Continuing the work in Guardian
Code-review findings can be assigned, tracked and reviewed alongside the rest of the customer security program.
Guardian can convert findings into risks and All Actions with engineering owners, release dates, remediation guidance, evidence and review history.
This gives product, security and leadership teams a common view of which defects block release, which fixes are in progress and which residual risks remain accepted or unresolved.
Questions buyers ask before engagement
Practical questions about Secure Code Review.
The final answer depends on the customer environment and scope, but these are the points that should be resolved before work begins.
Q1
How long will it take?
Timing depends on scope, access, environment stability, customer availability and the review depth required. The proposal states the expected delivery window and the assumptions that can change it.
Q2
Can the scope change after work starts?
Yes, but the change is recorded. Damocles explains the coverage, timing and commercial impact before additional work is performed.
Q3
Will Damocles work with our existing team or provider?
Yes. Internal teams, developers, cloud partners, infrastructure providers and MSPs can participate where responsibilities, access and communication paths are clear.
Q4
How are findings prioritised?
Priority considers practical exploitability or failure likelihood, exposure, affected business capability, data, privilege, dependency, available compensating controls and remediation effort.
Q5
Is remediation included?
Remediation guidance and handover are included as stated in the proposal. Implementation, managed change, emergency work and extensive engineering are separate unless expressly included.
Q6
How is closure verified?
Closure uses the method suitable for the issue: retesting, rescanning, code or configuration review, operational evidence, restored source health, tabletop follow-up or another agreed validation method.
Scope, assumptions and boundaries
The review covers the agreed code, dependencies and execution context—not every system around the application.
Cloud configuration, network security, production runtime, third-party SaaS behaviour, mobile binaries, infrastructure and operational monitoring are included only where expressly added to scope.
Secure Code Review cannot guarantee the absence of defects. Coverage depends on repository completeness, architecture context, review depth, code volume and the ability to validate behaviour.
Take the next practical step
Choose the release, component or trust boundary that needs the deepest review.
Share the technology stack, repository size, release timing, architecture and highest-risk business functions. We will define a review scope that produces useful engineering decisions.