// intro
last year i started building a passive resolver for chile's ley 21.663 anci registry because i needed to answer a simple question: how many critical infrastructure operators actually have a public disclosure channel? what started as a weekend script turned into a dns-verified, open-source dataset that maps canonical domain ownership across eight critical sectors.
this post tells the engineering story. the false positives that nearly broke the methodology. the naming patterns nobody documents. why heuristics alone fail in chile's corporate landscape. and what the final dataset reveals about coordinated disclosure readiness in a country that just passed its first critical infrastructure law.
if you're a researcher, a security practitioner working in chile, or someone building tooling for ley 21.663 compliance — i hope this is useful.
// the problem we encountered
ley 21.663 defines a universe of operators of vital infrastructure (oivs) across chile — designated by anci res. exenta 87 (16-dic-2025). before i could audit their disclosure channels, i needed to know which domain belonged to which operator. that sounds trivial. it's not.
take bci. banco de crédito e inversiones. its primary domain is bci.cl. but a naive regex lookup on "banco" returns bancochile.cl, bancobice.cl, bancointernacional.cl, and a dozen registro civil misattributions. the strings overlap. the institutional names overlap. a false positive at this layer cascades into every downstream analysis — you end up auditing the wrong entity's security.posture headers and calling it research.
bancoestado.cl was another case. it resolves. it's owned by bancoestado. but bancoestado's digital subsidiaries — bancoestado.com, cuentarut.cl, serviestado.cl — represent separate legal entities in the anci registry. each needs its own canonical entry or you undercount the attack surface by conflating them.
systematic false positives aren't an edge case. they're the default when you apply international tooling assumptions to chile's actual naming conventions. we found this pattern across energy, water, telecoms, and port operators. the resolver exists to make that mapping explicit, verified, and reusable.
// why existing tools fail
before building from scratch i tested three approaches: domain inference from company names (high noise), reverse whois lookups (incomplete for cl-tld registrations), and knockpy-style enumeration (active — wrong threat model for osint-only research). none produced a reliable canonical map.
the core issue is accent normalization. chile's corporate registry (sbif, cmf, tdlc) stores names with full utf-8 diacritics. domain registrars strip them. the company "administración portuaria" doesn't own administraciónportuaria.cl — it owns puertovalparaiso.cl or emporchi.cl or something historically named that has zero lexical overlap with its legal name. no amount of levenshtein distance calculation fixes this. you need human-verified ground truth.
beyond normalization, chile's sector-specific naming patterns don't generalize. energy companies use service brand names (enel.cl, colbun.cl). water utilities use geographic identifiers (aguas-araucania.cl). port operators use facility codes (stsi.cl). a single heuristic model that works for one sector actively misleads on another.
finally, the anci oiv list is itself heterogeneous. it includes state-owned enterprises, private concessionaires, municipal services, and regulatory bodies. the domain patterns for each category are structurally different. tooling that doesn't segment by sector and entity type cannot produce reliable coverage estimates.
// what we built
anci-oiv-resolver is a static json dataset and accompanying python cli that maps each anci-registered oiv to its canonical primary domain, verified through passive dns resolution. no active scanning. no requests to target infrastructure. pure osint.
the dataset schema is intentionally minimal:
{
"oiv_id": "E-001",
"legal_name": "empresa nacional de electricidad s.a.",
"canonical_domain": "endesa.cl",
"sector": "energia",
"dns_verified": true,
"verification_date": "2026-05-01",
"notes": "enel-branded internationally; endesa.cl is cl-primary"
}the cli wraps the dataset with lookup commands: by sector, by legal name substring, and by domain. it's designed to be piped into other tooling — pair it with a security headers scanner and you get sector-level disclosure channel audits in minutes, not days.
the license is apache 2.0. fork it. improve it. contribute entries. the dataset is only as good as its coverage, and the work of expanding it across the full anci universe is ongoing — pull requests are open.
// the coverage gap research
the resolver is infrastructure. the research it enables is the coverage gap framework — a companion paper that answers the question i started with: how many chile oivs have a public coordinated disclosure channel?
the headline finding: a structural coverage gap across the chilean oiv population — audited across security.txt presence, dedicated disclosure email, and responsible disclosure policy pages. the data reveals a significant gap between what ley 21.663 assumes (that operators are reachable for security reports) and what the infrastructure actually supports. the full quantitative findings are published in the paper — arXiv:2606.05594 · doi 10.5281/zenodo.20501960.
this isn't a commentary on operator intent. most organizations simply haven't built disclosure infrastructure because the regulatory mandate to do so is new. ley 21.663 passed in 2023. its subsidiary regulations are still being finalized. this is the baseline — the disclosure infrastructure floor at law-minus-two-years. watching it rise over the next 24 months as compliance obligations become concrete is the actual longitudinal research.
the resolver makes that longitudinal tracking tractable. re-run the audit script quarterly against the canonical domain set and the delta is your disclosure infrastructure growth rate. that's the paper companion's practical contribution: not just the finding, but the methodology to keep it current.
// what's next
three parallel tracks for q3 2026:
dataset expansion across the full anci universe. the hard entries are smaller operators, municipal entities, specialized concessionaires with minimal web presence. solving them requires sector-specific research strategies, not a generic lookup pipeline.
the coverage gap paper — published. what was a working paper when this post first went up is now out: published on arxiv as arXiv:2606.05594 (cs.CR), with a permanent doi via zenodo: 10.5281/zenodo.20501960 (cc-by-4.0). academic citable infrastructure for a law that will generate a decade of compliance research.
cna application path. chile's cna (coordinador nacional de ciberseguridad) program creates a pathway for independent researchers to operate formally within the ley 21.663 ecosystem. i'm evaluating that path as a way to establish institutional standing for the longitudinal audit work — because a study that runs for five years benefits from being grounded in a recognized framework.
a proposal for patagonia ciber 2026 (11-12 jun · talcahuano) is in review with anci; defcon and 8.8 computer security conference are on the cfp monitoring list for the q3 2026 cycle.
// contribute · feedback · contact
the resolver is open source. if you work in chile's critical infrastructure sector and can verify entries, spot errors, or fill gaps for specific operators — pull requests are open and welcome.
if you're a security researcher with coverage gap data, a journalist covering ley 21.663, or an operator trying to understand your own disclosure posture — david@reizan.io is the channel.
// research published via reizan · independent cybersec research advisory · canonical at reizan.io/papers
// siguiente_paso : ¿proyecto en mente?
iniciar_contacto →