Skip to content

Offensive security, processes and governance for the age of AI and open source

Code you didn't write. Risk you still own.

Scroll ↓

This is the code you wrote.

One repository. One team. One review process you trust.

This is what you ship.

Every dependency brings its own. Most of what runs in production was never read by anyone on your team.

Part of it, no one wrote.

Assistants and agents commit at machine speed: plausible code, unreviewed assumptions, packages that may not even exist.

One link is enough.

One stolen maintainer token. One install script. It reaches your build before it reaches your changelog.

The evidence

Who we are

ANTEMUR is a security firm with one obsession: the code inside your product that no one on your team wrote. We attack it the way an adversary would, before an adversary does.

ante murum/ˈan.te ˈmuː.rum/Latin, “before the wall”

The ground in front of the wall, held by the redan: a V-shaped outwork with its point facing the enemy. It takes the assault first. That V is our logo.

Traditional application security guards the wall: your code, your perimeter. The attacks of this decade arrive through what you import and what you generate. That is where we stand. Technology alone does not hold. We also secure the processes and governance around it, from policy to incident response.

Our focus / Front 01

AI-generated code

Speed changed. Review did not. We audit what assistants and agents put into your repository, and the tools that put it there.

  • 01Hallucinated and slopsquatted packages

  • 02Insecure defaults in generated code

  • 03Secrets exposed in prompts and output

  • 04Prompt injection against coding agents

  • 05Poisoned rules files and MCP servers

  • 06Excessive agent permissions in CI

Our focus / Front 02

Third-party code

Every package, action and SDK is a trust decision. We map who you really trust, and what happens when that trust breaks.

  • 01Maintainer takeover and token theft

  • 02Typosquatting and dependency confusion

  • 03Malicious install scripts

  • 04Reachable transitive vulnerabilities

  • 05Compromised CI actions and build pipelines

  • 06Abandoned and unowned components

Our focus / Front 03

Process and governance

Secure software does not survive insecure decisions. We structure how your company approves, controls, responds and answers for its risk.

Frameworks we work with

  • ISO/IEC 27001
  • ISO/IEC 42001
  • NIST CSF 2.0
  • NIST SSDF
  • SOC 2
  • LGPD
  • GDPR

  • 01Security governance, policies and ownership

  • 02Risk management and executive reporting

  • 03Third-party and vendor risk

  • 04AI usage policy and controls

  • 05Access, change and secure development processes

  • 06Incident response plans and tabletop exercises

Core techniques

How we hunt

  1. Provenance mapping

    An SBOM and AI-BOM of what really ships: every component, every origin, every line an agent authored.

    $ sbom.cdx.json / ai-bom.json

  2. Reachability analysis

    We trace call paths from your entry points to each vulnerable function, so severity reflects what an attacker can actually reach.

    $ entrypoint → sink: reachable

  3. Taint analysis

    Untrusted input followed from source to sink, through generated and imported code alike.

    $ source → sanitizer? → sink

  4. Package detonation

    Suspicious packages run in an instrumented sandbox. Network, filesystem and process behavior are recorded, not assumed.

    $ postinstall → outbound call → flagged

  5. Agent red teaming

    Prompt injection, tool abuse and context poisoning, aimed at your coding agents and MCP integrations.

    $ injection → tool call → impact

  6. Pipeline audit

    Build integrity checked against SLSA: pinned actions, signed artifacts, scoped tokens, verifiable provenance.

    $ slsa: build track review

  7. Manual exploitation

    Automation finds candidates. Engineers prove them. No working proof of concept, no place in the report.

    $ poc: reproducible

  8. Governance assessment

    Policies, roles, controls and evidence reviewed against how your company really operates and the frameworks it answers to.

    $ control → owner → evidence

Method

Four moves. No theater.

  1. 01

    Map

    We inventory your code, dependencies, agents, pipelines and internal processes.

    You receiveExposure map

  2. 02

    Attack

    We run adversary techniques against the real paths into your product.

    You receiveAttack log

  3. 03

    Prove

    Every finding comes with reproduction steps and measured impact.

    You receiveEvidence report

  4. 04

    Fortify

    Fixes, policies and guardrails go into your pipeline. Then we test again.

    You receiveHardening plan and retest

Public record

This is not hypothetical.

  1. 2018

    event-stream

    A new maintainer gained publish rights and added a dependency built to steal cryptocurrency wallets.

  2. 2020

    SolarWinds Orion

    Attackers compromised the build system. A signed update carried the backdoor to thousands of customers.

  3. 2021

    Log4Shell

    One string in a log line meant remote code execution in a library present almost everywhere.

    CVE-2021-44228 ↗

  4. 2024

    xz-utils

    After years of earning trust as a maintainer, an attacker planted a backdoor in a core compression library.

    CVE-2024-3094 ↗

  5. 2025

    tj-actions

    A widely used GitHub Action was compromised and exposed CI secrets in workflow logs.

    CVE-2025-30066 ↗

  6. 2025

    Shai-Hulud

    A self-replicating worm spread across npm using stolen maintainer credentials.

  7. 2026

    Mini Shai-Hulud

    New waves of the worm hit npm again, and copycats followed once its source code leaked.

References

Clients and references

Published only with each client's written authorization.

Start here

Find it before they do.

Tell us what you ship. We answer with a scope, not a sales deck.