Where the framework applies
OffSecDevOps concerns how offensive security work is organised and delivered. A maintained workflow supports selected activities within an authorised assessment or programme. The consultant chooses how to use it according to the adversarial objective, observations and rules of engagement.
A broad offensive security scope
The areas below show where a reusable capability may help. They are examples, not a coverage list for every engagement. The lead first defines what the assessment is intended to investigate, then selects suitable workflows and leaves room for consultant-led investigation.
Application and API testing
For an objective such as cross-tenant data access, a maintained workflow can compare designated account behaviour and retain requests and responses. The consultant still investigates other relevant routes, integrations or business-logic abuse when the scope and observations justify it. The SaaS walkthrough shows that distinction.
External infrastructure testing
Discovery and service enumeration can support an investigation of exposed entry points. The workflow records the authorised destinations and observations; the consultant decides which services merit closer examination. A newly discovered host requires a scope check before testing, even when it appears related to the client's infrastructure.
Internal network testing
From an agreed starting account, maintained enumeration can record directory relationships, privileges and relevant credential exposure. The consultant uses those observations to investigate possible routes to the designated objective. Further exploitation or lateral movement remains subject to the rules of engagement and any required approval.
Cloud environment testing
A workflow can collect evidence about identity permissions, cross-account trust or exposed storage in the authorised environment. The consultant examines whether those relationships could provide the access being investigated. Finding another reachable account, service or resource does not authorise activity against it.
Identity and access control
Selected comparisons can help investigate an objective such as a standard user performing a privileged operation. They need designated accounts, a confirmed session and an agreed expectation of permitted behaviour. The consultant may investigate relevant SSO, token, delegation or federation paths separately; supported denials in the selected role checks do not establish that every access path is secure.
Segmentation and attack-path analysis
A maintained procedure can preserve reachability and privilege evidence as the consultant develops an attack-path hypothesis. The next step follows the observations and authorised objective. Reporting distinguishes a demonstrated route from a plausible path whose required stages have not been tested.
AI-enabled and agentic applications
Here the application itself is the assessment target. Its use of tools, retrieval or persistent memory may be relevant to an objective such as obtaining data or causing an unauthorised action. The consultant selects those investigations according to the application's actual capabilities and the agreed scope.
Red teaming
A red team can use maintained workflows for selected preparation, operational activity and evidence handling. The objective and observations guide the operation, including decisions about further actions and their likely effects. Reusable procedures retain the agreed approval and intervention points without determining every step.
AI in the workflow and in the assessment target
A team may use AI to help perform an assessment, assess an application that uses AI, or do both. These decisions concern different boundaries. The framework also applies when no agent is involved.
AI-assisted testing
When an agent proposes or performs selected activity, the lead defines its role, reachable targets and data, tool permissions and approval points. A named practitioner reviews the relevant action or evidence. The team evaluates that configuration before relying on it; a suggestion cannot expand the engagement's authority.
Testing an AI-enabled application
The consultant investigates the target application's trust boundaries and delegated capabilities within the agreed scope. A test may examine whether an application's tool access crosses an intended boundary, for example. The assessment can be performed manually; the target's use of AI does not require the tester to use an agent.
What changes across domains
A small team can use its existing lead, workflow owner and evidence reviewer across these areas. The records and controls need to fit the work they support, rather than create a separate delivery process for every domain.
Different workflows
The owner defines the workflow's intended function for its environment. An API request comparison and directory enumeration need different prerequisites and evidence. The consultant decides how each contributes to the engagement's objective.
Different triggers
A planned pentest, a change in exposure or a recurring programme may justify activity. A software release can be relevant background, as in the SaaS example, but the authorised adversarial objective determines what is investigated.
Different control points
The lead agrees approval, stopping and recovery arrangements according to the likely effects of the activity. A read-only comparison against synthetic records and exploitation of a live service need different operating limits and review decisions.
A fixed-duration assessment and a recurring programme should each be judged on whether their delivery arrangements support the intended work. Execution frequency and autonomy alone do not establish the quality of the investigation.
Why the framework matters
Read how the framework helps a team assess workflow ownership, review effort and the quality of delivery decisions.
Go to why it matters