OffSecDevOps
A practical framework for engineering offensive security delivery.
OffSecDevOps is a practitioner-developed framework for organising and maintaining offensive security delivery. It helps a team decide how to prepare and operate its workflows, who reviews their evidence, and what must change before they can be relied on during an engagement. It applies to consultancy assessments and internal offensive security programmes, including work performed without automation or AI.
The operating model
The operating model describes five capabilities a team needs across an engagement. For example, an attack-path investigation needs suitable tools, clear authority and inspectable evidence while the consultant decides what to pursue next. The capabilities below support that work throughout preparation, execution and review; they are not successive stages or a prescribed sequence of tests.
Maintained workflows
An owner maintains methods for suitable recurring activities. Consultants can use them without relying on the author's local setup or undocumented knowledge.
Controlled execution
The engagement lead agrees permitted activity and stop conditions. Consultants apply those limits to their own work and to any tools or agents they operate.
Evidence and records
Another practitioner can establish what was attempted, which account or starting position was used, and what evidence supports each conclusion.
Accountable decisions
A named representative authorises scope. The engagement lead reviews proposed actions, and a competent reviewer inspects the evidence behind findings before they enter the report.
Deliberate improvement
The workflow owner uses recorded failures and review feedback to make changes, then evaluates their behaviour before wider engagement use.
A team may have reliable tooling but weak evidence capture, or good review practices but no time allocated to maintenance. Consider the consequence of each gap rather than averaging them into one score. The consultant still directs the investigation towards the authorised objectives.
Operating principles
A workflow can be a documented manual procedure, a script or a combination of tools and review steps. It supports selected parts of an assessment, such as enumeration or access-control comparisons. Versioning, evaluation and maintenance make that capability usable by the team; they do not turn exploratory assessment work into a fixed script.
Reuse where it helps
Maintain recurring activities where a shared method helps. The consultant chooses relevant checks and follows observations that warrant further investigation within the engagement's authority.
Reflect authority in tools and access
Document permitted targets and actions, and restrict destinations, credentials and tool permissions where feasible. Agree which actions need a separate decision. Discovering a reachable target does not authorise testing it.
Delegate according to evidence and risk
The technical lead decides what a tool or agent may do using evaluation evidence for that activity and the consequences of failure. Reviewers need enough context and time to challenge a result or stop the work.
Separate completion from a conclusion
A completed workflow does not establish that an engagement's objectives have been adequately investigated. Record execution problems and untested work, and limit report conclusions to the supporting evidence.
Control what is reused
The owner reviews and sanitises a useful test pattern before sharing it. Client evidence remains subject to the engagement's data-handling arrangements; it must not automatically enter another engagement, shared agent memory or training data.
Start with a delivery problem
Choose an activity whose weakness affects an engagement. If candidate findings arrive without enough evidence to validate them, the technical lead can trace a representative result back to its requests, account context and expected behaviour. That helps identify capture or interpretation problems. The delivery manager also compares the review queue with the time allocated to it.
Give the correction an owner and check it on suitable examples before wider use. Compare the resulting engagement effort, including validation and report rework, rather than treating faster execution as the saving. The delivery failure modes give practical starting points; the SaaS penetration-test walkthrough shows how a maintained workflow fits an investigation.
How teams might evolve
These proposed discussion levels help a team describe what it can demonstrate and what needs work. They are not a validated maturity model, assessment standard or certification. Apply them to individual capabilities: a material evidence or scope weakness still needs attention even if other areas are well maintained. Testing frequency and degree of autonomy are separate operating choices, not scores to maximise.
Level 1 | Controlled delivery
Work has an agreed purpose, scope and operating limits. Responsibilities, evidence requirements and stop procedures are clear.
Level 2 | Maintained workflows
Suitable activities use versioned workflows with named owners. Relevant evaluation supports their intended use, and another practitioner can operate them from the recorded instructions.
Level 3 | Integrated delivery
Assessment activity follows the programme's objectives and agreed triggers. Supported findings reach an owner for remediation or risk acceptance, with targeted retesting where agreed.
Level 4 | Demonstrated improvement
The team evaluates changes before wider use and compares similar engagements. Evidence shows what improved, such as reduced report rework, alongside any added review or maintenance effort.
See where the model applies
The same delivery capabilities can be applied across application, infrastructure, cloud and identity testing, red teaming, and assessments of AI-enabled applications.
Go to scope