Open Asset Model: Building a Graph-Based Specification for Attack Surface Management
Hook
When asked if an attack surface is just internet infrastructure assets, the creator of one of security’s most popular reconnaissance tools said no—then built a specification to prove it.
Context
Asset inventory tools have proliferated across security operations, but they all speak different languages. One tool tracks domains in JSON with custom schemas, another stores IP addresses in a proprietary database format, and your vendor’s API returns autonomous systems in yet another structure. When you need to correlate a domain to its hosting provider’s netblock, you’re writing bespoke integration code. Even worse, the focus has remained stubbornly narrow: domains, IPs, and ports, as if your attack surface ends where DNS records stop.
The OWASP Amass team recognized this fragmentation while watching their reconnaissance tool get adopted across thousands of organizations. They saw teams building brittle pipelines to transform Amass output into formats digestible by other tools, saw the security industry collectively ignore that attack surfaces include SaaS accounts, mobile apps, and third-party vendors, and saw an opportunity. Open Asset Model emerged as a specification-first approach to defining what an asset is, how assets relate to each other, and how tools should exchange this information. It’s a bet that standardization—not another proprietary format—will finally let security tools interoperate.
Technical Insight
Open Asset Model structures assets as typed entities with explicit relationships, implementing what appears to be a graph-based model in Go. The specification currently defines five core asset types—FQDN, IPAddress, AutonomousSystem, Netblock, and RIR Organization—each carrying attributes and maintaining references to related entities. This isn’t just data modeling; it’s encoding real-world infrastructure topology into a traversable structure.
The relationship modeling is where the design shows its sophistication. Rather than storing simple references, the model treats relationships as semantic connections between assets. When an FQDN resolves to an IP address, that represents a different relationship type than when an IP address belongs to a netblock. The specification aims to enable tools to traverse from a domain through its DNS resolution to the owning autonomous system, following typed edges that preserve context at each hop.
This design choice appears intended to enable rich queries that span asset types. Want to find all domains that resolve to IPs within netblocks owned by a specific organization? The model is designed to support traversing FQDN → IPAddress → Netblock → Organization relationships, making these multi-hop queries explicit rather than forcing reconstruction of relationships from flat data.
The transport specification aspect means Open Asset Model assets are designed to serialize to JSON or other formats while preserving type information and relationships. An asset collection tool like Amass could emit Open Asset Model entities, a vulnerability scanner could consume them to know what to scan, and an asset management database could ingest them for long-term storage—all without custom translation layers, at least in theory.
Extensibility is a core design principle. The roadmap includes certificates, tech stack information, API endpoints, mobile applications, social applications, accounts and credentials, cloud vendors, personnel, and physical locations—all intended to slot into the same relationship graph. The current five asset types focused on network infrastructure represent just the initial implementation of a much more comprehensive vision for modeling complete attack surfaces.
Gotcha
The current implementation lives squarely in the gap between ambitious vision and present reality. Right now, you get five asset types focused exclusively on network infrastructure: FQDN, AutonomousSystem, RIR Organization, IPAddress, and Netblock. Those roadmap items—mobile apps, personnel, cloud vendors, social media accounts, certificates, API endpoints—remain explicitly listed as future plans. If you’re building a tool that needs to model cloud resources, SaaS accounts, or really anything beyond traditional network recon, you’ll be extending the model yourself or waiting for community contributions that may never materialize.
Language support is another constraint. This is a Go library, full stop. The README explicitly acknowledges multi-language support as a future plan, but today there’s no Python package, no JavaScript module, no Java implementation. If your security stack isn’t Go-based, you’re either wrapping the Go implementation (adding complexity), manually implementing the specification in your target language (defeating the interoperability purpose), or choosing a different approach entirely. For a project aiming to become a universal transport specification, single-language availability is a significant adoption barrier.
More fundamentally, standardization only works when there’s critical mass. With 58 GitHub stars and limited ecosystem adoption visible in the metadata, Open Asset Model hasn’t yet achieved the network effects that make standards valuable. Using it today means betting that tooling will coalesce around this specification rather than one of the alternatives—or that you’ll drive enough of the ecosystem yourself to make it worthwhile. Early adopters carry the standardization burden.
Verdict
Use Open Asset Model if you’re building security tooling in Go that models network infrastructure relationships, especially if you’re already in the OWASP Amass ecosystem or want to contribute to defining what attack surface management standards should look like. The relationship-based approach to modeling how domains, IPs, ASNs, and netblocks interconnect is conceptually sound for capturing infrastructure topology, and having a specification beats inventing your own schema if you’re starting from scratch. It’s also ideal if you’re positioned to influence an emerging standard and see value in shaping the direction. Skip it if you need comprehensive asset coverage beyond network infrastructure today, if your stack isn’t Go-native and you can’t justify the integration cost, or if you need a battle-tested standard with broad tool support right now. The project represents solid architectural thinking applied to a real interoperability problem, but it’s early-stage infrastructure for a future that hasn’t fully arrived. With only five asset types currently implemented and significant portions of the vision still on the roadmap, you’re adopting both a specification and a commitment to help build it out.
