Case study - Cloud security · CSPM / CIEM · Australia
Automated cloud security assessments
A cloud-security platform for consulting teams, MSPs and MSSPs. It maps a client's cloud estate (Azure, AWS, Entra ID, Microsoft 365), models it as a typed graph of resources and identities, finds the attack paths that graph makes possible, and generates the client-ready assessment report at the end of the run - turning days of manual scripting and report writing into a single automated run.
01 The challenge
A mid-sized cloud tenant produces thousands of misconfiguration findings, and the customer's real question is never "what is wrong?" - it's "what do I do on Monday morning?" The old workflow answered it with PowerShell scripts, spreadsheets, screenshots, and days of manual report writing per assessment.
Argos's answer had two load-bearing pillars:
Make cloud risk visible as structure
Not a flat list of findings, but a map of the client's cloud estate showing how identities, permissions and resources chain into realistic attack paths. Risk lives in the relationships, not in the rows - so the product had to model it that way before it could show it.
Make the deliverable automatic
The client-ready report - findings, diagrams, evidence - generated by the platform instead of written by hand over days.
When I joined, Argos was at an early stage - a single Azure Functions app, and none of this existed. The founder brought the security expertise and knew exactly what the product had to do. Building the machine that could do it was my side of the table.
02 The outcome
MSPs and security consultancies across Germany, the UK and Australia use Argos for assessments and ongoing monitoring - each assessment a workflow that once cost a consultant days of hands-on work, run unattended. The product is live at www.argos-security.io.
Argos today computes the provably minimal set of changes that closes every attack path in a customer's estate. That feature isn't mine.
It was possible because the expensive prerequisite it needed was already there: a typed graph of the estate with attack paths modelled in it. That prerequisite is the system I built.
The public positioning leads with the cloud-estate graph and the automated reporting. Per the founder, the graph was the product's standout feature at launch; today, report generation is the core workflow customers run the platform for.
A long-running engagement across five years, on demand, with repeated returns to the hardest parts of the product.
Over the years ARGOS has assessed over 5 million cloud resources, in dozens of tenants, across Azure, Entra ID, M365, and AWS. Processes that consultants used to spend days or weeks on can now be completed in hours, providing real, provable recommendations on what to fix, and why.
03 The foundation
I redesigned the original app's architecture and split it into four independently deployable services: the API, scanning, reporting, and the shared work underneath them.
That gave the platform independent scalability - each service scales on its own load rather than the whole system scaling as one block - fault isolation, so a failure in one doesn't take the others down with it, and independent deployability, so one part can change without redeploying the rest.
An assessment itself runs as a pipeline of long-running workflows, chained one into the next:
Inventory the client's cloud - every resource and identity, across every subscription and every connected cloud.
Turn that inventory into the structured graph of the estate: what exists, what contains what, and who can reach what.
Run the security checks across the graph and compute the attack and lateral-movement paths it makes possible.
Assemble the client-ready document from the result.
Those stages run on three subsystems - the scan engine, the graph, and the reporting pipeline. That is the application core, built on three principles that had to hold across the whole platform:
Parallelism. Resources are collected in parallel, checks run in parallel, report sections build in parallel. Run sequentially, an assessment across tens of thousands of resources would take many times longer than it does.
Resilience. An assessment runs far longer than any single cloud function is allowed to live, and cloud APIs fail transiently at this scale as a matter of routine. Each stage keeps its own state and continues from where it stopped rather than starting over.
Extensibility. A new inventory provider or security rule is picked up automatically - nobody wires anything up, and nobody can forget to. That is why the security content could scale independently of the engineering: nothing in the platform has to change to accept it.
04 The graph
The model everything else reads, and I owned it end to end - the resource registry, the relationship model, the builder, and the visualization itself.
A single registry describes every resource type the platform understands: what it is called, how it is shown, what can contain it, what it can connect to. The shape of the graph is defined there - not just its appearance.
The graph is built from the client's real estate: each resource arrives with its configuration, and the connections are read from it - what it belongs to, what it points at, who can act on it. Edges aren't anonymous lines: containment, membership, role assignment, network peering, and what an identity can actually do to a resource are distinct, named things. The payoff is legibility - a rendered attack path reads as a sentence ("assigned to → has role on → can execute on → runs as → can extract credential") rather than a chain of unlabelled arrows.
Once the estate is a graph, an attack path - how identities, permissions and resources combine into a route an attacker could take - becomes something the platform computes rather than something a consultant reconstructs by hand. Lateral movement is the part that runs across the network: starting from a machine exposed to the internet, the platform walks the graph to every machine reachable from it.
The renderer draws a focused view: around the resource in question, only what explains it - the branch of the estate it hangs off, any attack or lateral-movement path it sits on, and its immediate neighbourhood. From there the view is the analyst's to shape - filter by resource type, attack path, lateral-movement path or violated rule, group and collapse branches, drag anything into the arrangement that makes the case clearest - instant, because the whole graph is already in the browser.
Three ways of looking at the same thing. Each layout shows the attack chains; which one is useful depends on the question being asked.
Clustered - related resources pull together, so the shape of the environment reads at a glance.
The boxed view - network boundaries and what lives inside them.
Hierarchical levels - attack chains with a clear direction of travel.
A feature in its own right. Diagrams are now a product feature: discovered resources and relationships turned into cloud architecture diagrams automatically, ready for technical reviews, customer workshops, remediation planning and assessment reports.
05 The scan engine
The engine that drives an assessment: it inventories the client's estate, runs the graph build over that inventory, and evaluates the security content against the result - unattended, across tens of thousands of resources, in a single run. The same run serves both ways the product is sold: a one-off assessment, or continuous monitoring.
Fix something in the cloud, and the finding closes itself on the next run. Every run is reconciled against what the platform already knows rather than piled on top of it.
Large tenants will exhaust a serverless worker outright. Results move through the pipeline as a stream and are processed in batches, so tenant size stops being the thing that decides whether a scan finishes.
Inventory providers register automatically per cloud, and their data models are generated from the cloud vendor's own definitions rather than hand-written.
The rule contract fixes what a rule declares and what the platform does with it: evaluate it, publish it, retire it. On top of it sit optional capabilities - a rule that can apply its own fix, a fix that can be rolled back - and the metadata every downstream part of the product reads. That contract is what let the founder keep adding rules by the hundred.
06 The reporting
Client-ready assessment reports generated end to end from platform data, with the graphs embedded as rendered images inside the document.
Assessment data injected into an HTML template.
The template rendered in a browser environment, where the graphs actually draw themselves.
The rendered graphs pulled out as SVGs and staged in temporary storage.
The final Word document is put together with each graph written into its place.
The whole flow runs as a chain of small serverless steps, processing in chunks, because the assembled document can be larger than the memory of the worker assembling it.
What comes out. One document carrying the executive summary, the prioritised risks, the attack paths, the architecture diagrams, the technical evidence behind each finding, the remediation guidance and the compliance mapping - assembled by the pipeline, ready to go to the client.
Report content and structure evolved under the founder's direction and were later reworked by him; the generation workflow and the machinery were mine.
07 Who did what
A core engineer on Argos across a five-year engagement - the engineering side of a two-person core, working directly with the founder with nothing in between.
The platform kept going. The features Argos demos today were built after me, on top of what I built - and that is the point. None of them required the foundation to be rebuilt first. A foundation is proven by what gets built on it without being torn up.
Deep, not wide: three subsystems built from scratch in one product, each taken from architecture to shipped feature.
Solo, pre-AI: the foundations were built before AI coding assistants were capable of meaningful help - the design and implementation of every stage above was one engineer's work.
08 The review
I can't recommend Alex highly enough. To any startup team where the MVP needs to be built, or turned into a real product even the largest Enterprises are willing to pay for. To any existing technical team looking for their new Principal Engineer to ensure the team is working towards a common set of rules.
Alex took a task and ran with it and helped turn ARGOS into a well-oiled machine that just keeps running.
David O'Brien on LinkedIn (opens in a new tab)Founder · Argos Cloud Security 09 Contact
Argos exists because raw security data is useless until a human can understand it. That's also how I build software. You bring the intent - often a sentence, sometimes a sketch; what turns it into a feature is someone who takes the architecture, the interaction and the code as one job and stays accountable for the result. Have a load-bearing feature you can't get to? I take slices like that end-to-end.
alex@cyber-architects.com