ASM (Attack Surface Management): por que olhar seu site como um atacante

Most companies know how to defend what they remember they have. The real problem lives in what they forgot: the 2021 subdomain, the public S3 bucket from when someone tested a backup, the .env that accidentally got committed, the staging admin panel that stayed online.

These things appear and disappear without security ever seeing them. ASM exists to close that blind spot.

What ASM is

Attack Surface Management is the discipline that:

1. Discovers everything your company exposes to the internet, continuously.
2. Inventories each asset with a fingerprint (technology, version, function).
3. Assesses the risk of each one (CVE, configuration, headers, certificate).
4. Alerts when something new appears, when something known gets worse, when something critical goes public.

The angle matters: ASM is external observation, no agent, no login. It sees what an attacker sees.

ASM ≠ pentest, ≠ EDR, ≠ vulnerability scanner

The most common confusion is ASM with vulnerability scanner. A scanner needs the list of IPs. ASM discovers the list. That's the difference between being handed an inventory and building one.

What goes into the "attack surface"

A typical company's external surface:

DNS layer

• Main domain and registered variants (.com, .io, .app)
• Subdomains (discovered via brute force + Certificate Transparency + zone transfer + passive scraping)
• Suspicious DNS records (orphan MX, CNAMEs pointing to dead services — vector for subdomain takeover)

TLS layer

• Certificates across all domains
• Expiry dates
• Chain and algorithms
• Enabled TLS versions

HTTP layer

• Detected technologies (web server, framework, CMS, CDN, analytics)
• Exposed versions (banner, ?ver=, meta generator)
• Security headers present/absent
• Sensitive endpoints open (/admin, /.git/, /.env, /wp-json/wp/v2/users)

Port layer

• Open TCP/UDP ports on public IPs
• Service banners (SSH, FTP, SMTP, RDP, exposed database)

Email layer

• SPF, DKIM, DMARC configuration
• Sender IP reputation
• DMARC with p=none on an email-sending domain

Identity layer

• Exposed login panels (/wp-admin, /admin, /login)
• Brute-force possible? Rate-limit working?
• Misconfigured SSO, open OAuth callback

Code layer (when you connect a repo)

• Leaked secrets (AWS_SECRET, tokens, committed .env)
• Vulnerable dependencies (SCA)
• Insecure patterns in your code (SAST)

The ASM cycle

Runs 24/7:

Discovery → Inventory → Assessment → Prioritization → Alert → Remediation → (loop)

The most neglected part is discovery. Companies doing ASM "manually" always find 60% of what they have, miss the rest, and the missed 40% is exactly where the incident happens.

Why ASM is the first thing to do, not the last

The pyramid I see at a new client:

1. Bought EDR for corporate endpoints.
2. Bought a WAF for the main site.
3. Bought a SIEM to correlate logs.
4. Never mapped what's exposed on the internet.

When we run the first ASM scan, an average mid-size client gets 3–7 surprises: orphan subdomain, public bucket, staging panel online, .sql backup in a served folder, repo with a secret. None of those would be caught by EDR or WAF — because the attacker doesn't even need to pass through those layers.

Without a map, defense becomes an illusion.

How to start (in the right order)

1. Raw external inventory: all company domains (finance has WHOIS records), all public IPs (company ASN, cloud ranges), all subdomains via crt.sh.
2. Triage by type: brochure site, app, API, exposed internal panel, forgotten microservice. Each demands different attention.
3. Technical assessment: TLS, headers, ports, fingerprint, CVE matching.
4. Prioritization by impact: public admin panel > brochure site missing a header. Don't treat everything equally.
5. Continuous automation: step 1 isn't a one-off. It's a process. New subdomains are born every week.

Where Sentinela fits

We're ASM with an A–F score. You drop in your domain and we:

• Discover subdomains (DNS + CT logs + brute)
• Map technologies, versions, headers, certificates, ports
• Cross-reference public CVE and EPSS data to prioritize
• Alert on drift (new service appeared, HSTS gone, certificate expiring)
• Connect to your repo for SAST and secret scanning
• Show score evolution over time

For the relationship between continuous ASM and point-in-time pentests, see annual pentest vs continuous auditing — they complement each other, but ASM covers the time between pentests.

The simple rule

You can't defend what you can't see. ASM is the act of seeing first. Before the firewall, before EDR, before SIEM — before everything: map your external surface, and keep the map fresh.

The attacker is already doing this against you. The question is whether you're doing it too.