ADINT to Stack Discriminator
Turn official careers pages and public ATS postings into role-attributed stack claims, product-boundary hypotheses, and cheap current checks that can reject them.
Enter with artifacts, leave with evidence.
- backend or platform opening
- SRE or infrastructure opening
- developer, data, identity, mobile, or security opening
- migration or legacy language in a job description
- engineering post
- status component
- public repository
- deprecation notice
- official careers page or public ATS board linked by the target
- current in-scope asset family
- no personal-data collection
Agents can search this workflow, retrieve the complete graph, or request one stage through the read-only Vulns.co MCP connector.
Build the role-to-stack matrix
Record the official source, URL, dates, exact supporting text, role family, team or product area, named technology, lifecycle language, and requirement class. Group backend, platform, SRE, infrastructure, data, identity, mobile, developer experience, release, and security roles without losing product ownership or verbs such as operate, migrate, replace, deprecate, and modernize.
- official careers page or public ATS posting
- dated careers technology matrix
- migration and legacy clues
- Evidence gate
- Every technology remains attached to a faithful source excerpt, role family, product area, lifecycle phrase, dates, and source URL.
- Negative control
- Generic skill keywords, evergreen templates, copied recruiter text, corporate IT roles, and unrelated acquired-company material remain weak evidence.
- Stop condition
- Collect no applicant fields, employee contact details, personal profiles, or non-public material. Never call an application submission endpoint, and do not infer a company-wide stack from one region, vendor integration, or acquired product.
Seek an independent corroborator
Compare official docs, release notes, public repositories, package manifests, status components, current client artifacts, API contracts, and response behavior for the same product area and time window.
- dated careers technology matrix
- public product artifacts
- supporting or contradictory evidence
- confidence label
- Evidence gate
- Confidence rises only when an independent source supports the same product area and time window.
- Negative control
- A vendor page, duplicated posting, or repeated role template alone does not establish deployment.
- Stop condition
- Do not use discovered credentials or private repository access.
Map the likely boundary
Translate the supported claim into one concrete boundary such as GraphQL gateway to resolver, browser to OIDC issuer, proxy to service mesh, producer to Kafka consumer, parser to document pipeline, ORM authorization to data object, or CI runner to artifact registry.
- corroborated stack claim
- boundary hypothesis
- expected observable
- Evidence gate
- The boundary names both sides, the trusted data, the associated product surface, and an observable that could reject the claim.
- Negative control
- A generic technology label with no affected product surface stays in backlog.
- Stop condition
- Do not select an exploit before reachability is supported.
Run one safe live discriminator
Use current headers, scripts, source maps, documented public APIs, OIDC discovery, error shapes, or one non-state-changing request to support or reject the boundary hypothesis.
- expected observable
- current scope
- supported, rejected, or unknown claim
- next review date
- Evidence gate
- Raw current evidence agrees with the claimed product area and differs from a known control.
- Negative control
- A generic CDN, shared SaaS page, or unrelated host does not count as stack confirmation.
- Stop condition
- Stop when the check would require broad scanning, credential use, state change, or off-scope access.
Continue with the right depth.
References
- https://developer.greenhouse.io/job-board.html ↗
- https://github.com/lever/postings-api ↗
- https://developers.ashbyhq.com/docs/public-job-posting-api ↗
- https://docs.github.com/en/rest/repos ↗
- https://spec.openapis.org/oas/v3.1.1.html ↗
- https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/01-Information_Gathering/10-Map_Application_Architecture/ ↗