# OWASP Amass: attack surface mapping and external asset discovery in Go

> Amass is an OWASP flagship project that maps an organisation's external attack surface by combining open source intelligence with active reconnaissance. It is a Go program with a Docker image and a set of companion binaries, and its v5 line splits the work into an engine, an enumeration tool and a local asset database.

**owasp-amass/amass** — In-depth attack surface mapping and asset discovery

- Repository: https://github.com/owasp-amass/amass
- Website: https://owasp.org/www-project-amass/
- Stars: 15,239 · Forks: 2,190
- Language: Go
- License: NOASSERTION
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/owasp-amass-amass

## What Amass is for, and who actually needs it

Amass maps an organisation's external attack surface. The README describes the project as performing "network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques." Those are two different activities glued into one pipeline, and the distinction matters when you decide whether to run it. Open source information gathering means pulling names and relationships from third-party sources. Active reconnaissance means sending DNS queries and HTTP requests to systems you have named. The second half is what makes authorisation non-negotiable.

The audience is narrower than the download numbers suggest. If you are a penetration tester scoping an engagement, a bug bounty hunter working inside a program's defined scope, or a security engineer who needs an inventory of which hostnames and IP ranges belong to your employer, Amass is built for that job. If you want a single hostname resolved once, dig or host is faster and has no configuration surface. Amass earns its complexity when the question is "what does this organisation expose" rather than "what is the IP of this one name".

The OWASP flagship status is a governance fact, not a quality claim. What it tells you is that the project sits under an organisation with a published project tier system, and that the repository is not archived. The last push was on 2026-07-19, roughly two months before this writing, and the most recent tagged release listed is v5.1.1 from 2026-04-07. That is a project still receiving commits, with release cadence measured in months rather than weeks.

## The v5 architecture: engine, asset database and the OAM schema

The most consequential thing about Amass v5 is visible in go.mod rather than the README. The module is github.com/owasp-amass/amass/v5, and its direct dependencies include github.com/owasp-amass/asset-db, github.com/owasp-amass/open-asset-model and github.com/owasp-amass/resolve. Those three modules define the shape of the tool. open-asset-model supplies the asset types. asset-db supplies storage for them. resolve handles name resolution. Amass itself is the collection layer on top.

That means the data flow is not "scan, print, exit". Assets discovered by a data source or by active probing are converted into open-asset-model records and written into the asset database. Later operations query that database instead of re-running discovery. The Dockerfile confirms the split at the binary level: it builds and copies amass, oam_enum, amass_engine, ae_isready, oam_subs, oam_assoc, oam_viz, oam_track and oam_i2y into the image. Nine binaries, each with a narrower job than the monolithic amass command.

The naming is a reasonable guide to what each does. oam_enum is the enumeration entry point. amass_engine is the long-running engine. ae_isready is a readiness probe, presumably for checking that the engine and its database are up. oam_subs deals with subdomains, oam_assoc with associations between assets, oam_viz with visualisation, oam_track with tracking changes over time, and oam_i2y with converting internal records to an external format (the i2y suffix points at YAML, though the README does not spell this out). The README does not document the individual flags or subcommands of these binaries. That documentation lives in the separate Amass Docs repository, which the README links to directly.

The other dependency worth noting is modernc.org/sqlite. That is a pure-Go SQLite implementation, which is consistent with the Dockerfile setting CGO_ENABLED=0 so the build produces a static binary. A local SQLite-backed asset store is the practical consequence: you get a queryable file on disk, not a remote service you have to run.

## Installing Amass and running a first enumeration

The README points to the Amass Docs repository for installation instructions and documentation, and gives a Docker image reference in its badge row (owaspamass/amass on Docker Hub). Those are the two paths the project itself advertises. There is no install command in the README body itself, so the snippets below come from the Dockerfile and go.mod in the repository rather than from a documented quickstart.

The Dockerfile builds from golang:1.26.0-alpine and runs on alpine:latest. It sets HOME to /, creates a user named user, and creates /.config/amass owned by that user, plus a /data working directory. The entrypoint is /bin/amass. If you build it yourself, the first stage runs go install -v ./... with CGO_ENABLED=0, which is what produces all nine binaries.

```dockerfile
FROM golang:1.26.0-alpine AS build
RUN apk --no-cache add git
WORKDIR /go/src/github.com/owasp-amass/amass
COPY . .
RUN CGO_ENABLED=0 go install -v ./...
```

To run the published image, mount a host directory at /data and one at /.config/amass so the configuration and the asset database survive container restarts. The Dockerfile's WORKDIR is /data, so relative output paths land there.

```dockerfile
FROM alpine:latest
RUN apk --no-cache add bash ca-certificates
ENV HOME=/
USER user
WORKDIR /data
STOPSIGNAL SIGINT
ENTRYPOINT ["/bin/amass"]
```

If you build from source instead, the module requires Go 1.26.0 or later, which is what go.mod declares. The build produces the amass command plus the oam_* and ae_* companions in your Go binary directory.

```bash
go install -v ./...
```

What you should see after the container or binary starts is a usage listing for the amass command. The README does not reproduce that usage text, so treat the flag list as something to read from the tool itself rather than from this article. The v5 workflow the binaries imply is: start the engine (amass_engine), confirm it is up (ae_isready), run enumeration against it (oam_enum), then query results with oam_subs or export them with oam_i2y. The README does not give a worked example of that sequence.

## Where Amass gets in your way

The first limitation is documentation placement. The README is essentially a project landing page: badges, a one-paragraph description, a pointer to the docs repo, supporter logos, a contributing section, a troubleshooting note that explicitly asks people not to open GitHub issues for support, and a licensing paragraph. It does not document a single command-line flag. If you are evaluating Amass from the repository alone, you cannot answer basic questions such as which data sources are on by default or how to point the tool at a specific database file. Everything substantive is in the separate docs repository, which is a different project to review.

The second is the operational footprint. A v5 install is not one binary you copy to a jump host. It is nine binaries, a configuration directory at ~/.config/amass, and an asset database that accumulates state. The Dockerfile's HOME=/ and the chown of /.config/amass exist precisely because the tool needs a writable config path. Running it in a container without mounting that path means your configuration and any file-backed database vanish with the container. That is a real deployment constraint, and the README does not discuss it.

The third is licensing ambiguity. The repository's license is reported as NOASSERTION, and the README states the program is under the Apache license with the note that "Some subcomponents have separate licenses." The Go module graph pulls in roughly fifty direct dependencies, including geziyor, gorilla/mux, gorilla/websocket, miekg/dns, likexian/whois, openrdap/rdap and modernc.org/sqlite. Each of those carries its own license. If you are bundling Amass into a commercial product, the separate-licenses sentence is the line to follow up on, not the Apache badge alone.

Finally, active reconnaissance has a legal boundary the README does not draw. The tool sends DNS queries and HTTP requests to discovered hosts. Running it against infrastructure you do not own or have written permission to test is a decision about authorisation, and the project's documentation is not the place that decision gets made.

## How Amass differs from a focused subdomain enumerator

The obvious comparison is with tools that do one slice of this job well. A dedicated subdomain brute forcer takes a wordlist, fires DNS queries, and prints names that resolve. That is a stateless, single-purpose design: input wordlist, output list, no database, no engine, no configuration directory.

Amass v5 inverts that. The asset database is the centre of the design, and enumeration is one of several ways to populate it. The open-asset-model dependency means results are typed records with relationships, not strings. The oam_assoc binary exists specifically to work with those relationships. The oam_track binary exists to compare the asset set over time. Neither of those capabilities makes sense in a tool that only prints resolved names.

That is the actual trade-off. You give up the simplicity of a stateless command and take on a stateful service with a schema, in exchange for being able to ask questions later without re-scanning. For a one-off enumeration during a short engagement, the focused tool wins on setup cost. For an ongoing inventory where you want to know what appeared since last month, the database-backed approach is the reason to accept the extra moving parts. Amass is not a better brute forcer; it is a different category of tool that happens to include brute forcing.

## Maintenance, upgrades and what the release history shows

The release list shows v5.0.0 on 2025-08-03, v5.0.1 on 2025-09-04, and v5.1.1 on 2026-04-07. That is a major version followed by a patch and then a minor release roughly seven months later. The last push to the default branch was 2026-07-19, so the repository has seen activity since the most recent tag. The project is not archived. It is also not on a weekly release train, and anyone planning to depend on it should expect to track the docs repository for migration notes between minor versions.

Upgrade cost is dominated by the asset database. Because asset-db is a separate versioned module (v0.24.4 in this go.mod) and open-asset-model is pinned to a pseudo-version dated 2026-03-06, a schema change in either can affect stored data. The README does not document a migration path for existing databases, and it does not document rollback. If you run Amass in production, the practical question to answer before upgrading is whether your existing asset database survives the new binary, and the repository does not answer it for you.

The licence picture needs the same treatment. Apache 2.0 is stated in the README, the repository reports NOASSERTION, and the README adds that some subcomponents have separate licenses. Those three statements are not in conflict, but they are not the same statement either, and the only way to resolve them is to read the LICENSE file and the licence headers of the dependencies you actually ship. That is a fact-gathering task, not a legal conclusion, and this article does not offer one.

## Conclusion

Adopt Amass if you are doing authorised external reconnaissance and want the results stored in a queryable asset database rather than a flat text file; the v5 layout with asset-db and the OAM schema is the reason to pick it over a single-purpose subdomain brute forcer. Do not adopt it if you need a one-command scanner with no local state, or if you cannot get authorisation for active DNS and HTTP probing against the target. Before committing, verify three things in the repository: how the config directory under .config/amass is populated in your environment, which data sources are enabled by default in the version you install, and whether the asset database backend you intend to use is the one the shipped binaries expect.

## FAQ

### How do I install Amass on Ubuntu or Kali Linux?

The README does not give distribution-specific install steps. It points to the separate Amass Docs repository for installation instructions and documentation, and its badge row references the owaspamass/amass Docker image. Kali and Ubuntu both package Amass, but the repository material does not describe those packages, so verify the version they ship before relying on it.

### How do I use Amass for subdomain enumeration?

The v5 Dockerfile builds a binary named oam_subs alongside amass, which the naming suggests is the subdomain-oriented entry point, and oam_enum for enumeration. The README does not document the flags for either, so the exact invocation has to come from the Amass Docs repository or from the binaries' own usage output.

### What is the Amass tool used for?

The README describes it as performing network mapping of attack surfaces and external asset discovery using open source information gathering and active reconnaissance techniques. It is an OWASP flagship project written in Go.

### How do I use Amass in Kali Linux?

The repository material does not describe Kali-specific usage. The two installation paths the README references are the Amass Docs repository and the owaspamass/amass Docker image, and the Dockerfile sets the entrypoint to /bin/amass with a working directory of /data.

### How do I install Amass?

The README directs readers to the Amass Docs repository for additional installation instructions and documentation, and its badge row links to the owaspamass/amass image on Docker Hub and to the GitHub releases page. The repository also contains a Dockerfile that builds all the shipped binaries from source.

## Sources

- [Issues](https://github.com/owasp-amass/amass/issues)
- [owasp-amass/amass on GitHub](https://github.com/owasp-amass/amass)
- [Project website](https://owasp.org/www-project-amass/)
- [README](https://github.com/owasp-amass/amass/blob/main/README.md)
- [Releases](https://github.com/owasp-amass/amass/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/owasp-amass-amass