Threat intelligence to detection engineering

Public roles at Notion, Figma and Ramp connect threat intelligence, vulnerability triage and remediation coordination with engineering work. These sources do not reveal one shared internal platform or prove a tooling gap. They do expose a useful design boundary: threat intelligence, vulnerability findings and incident reports need different evidence and decisions, even when a team wants one consistent intake and review experience.

What the Job Postings Explicitly Describe

A review of verified public job descriptions shows that growing software teams place vulnerability evaluation and threat translation directly within engineering responsibilities. In a posting for a Security Engineer in Detection and Response, Notion asks the role to "Translate threat intelligence and adversary TTPs into durable detections, telemetry requirements, and response improvements." The text explicitly details the conversion of external threat context into technical engineering outputs.

Similarly, Figma describes operational expectations in its Security Engineer posting, noting: "You will also participate in operational security responsibilities like security reviews, consulting, vulnerability triage, and security incident response." In the fintech sector, Ramp seeks a Product Security Engineer to "Lead remediation of prioritized issues across our technology stack: collaborating with other engineers to triage and fix vulnerabilities discovered internally, through penetration testing, and through our bug bounty program."

The listings establish that engineers are assigned work involving threat translation, vulnerability triage and remediation coordination. They do not establish the companies’ internal volume, workflow, automation or performance.

• Notion: translating threat intelligence and adversary techniques into detection and telemetry improvements.
• Figma: participating in security reviews, vulnerability triage and incident response.
• Ramp: coordinating remediation for findings from internal work, penetration tests and a bug bounty programme.

The Recurring Operational Responsibility Across Intake Streams

The duties share a handoff from external or dispersed evidence into engineering action, but the inputs are not interchangeable. Threat intelligence may lead to a detection hypothesis or telemetry requirement. A vulnerability report needs affected-asset and exploitability review. An incident record may require containment, evidence preservation and an approved escalation path.

A useful workflow preserves the source type, provenance, observation time, affected scope and confidence rather than flattening every item into a generic ticket. It can provide a common review shell while routing each class to its own required evidence, owner and decision policy.

This distinction is an architectural proposal for another team, not a description of how the cited companies operate internally.

Evaluating Workflow Recurrence and Friction Inside an Organisation

A job description proves that a duty exists, not how often it occurs or which software supports it. Evaluate threat-intelligence translation, vulnerability intake and incident handling separately before assuming one automation opportunity.

Use an authorised, representative sample to measure time spent locating evidence, identifying candidate ownership, requesting missing context and creating the next engineering artefact. Record unresolved items and reviewer corrections. Separate necessary investigation from avoidable copying or format conversion.

A bounded pilot should follow one recurring handoff with agreed evidence and reviewer authority, as described in the guide on how to scope an MVP without waste.

The Smallest Conditional Architecture for Intake Management

If a measured handoff remains repetitive after testing existing tool configuration, begin with one source type and one destination. For example, a pilot might attach approved threat indicators and relevant telemetry context to a detection-review record. It should not attempt to unify every security queue or make autonomous risk decisions.

Preserve the original source, retrieval time, parser version and permission boundary. Map only supported structured fields into a typed internal record, and represent missing or conflicting values explicitly. Free-text extraction remains a proposal requiring review even when it produces valid JSON.

A common record can reduce repeated formatting only if it preserves source-specific evidence and exception states. Compare that limited need with supported commercial configuration before selecting custom software, as discussed in custom software versus off the shelf SaaS.

Prioritising Deterministic Steps Before Generative Processing

Use rule-based checks for required fields, authorised sources, known identifiers and supported destinations before invoking a model. Deterministic code can make its own pass/fail decision reproducible, but it cannot prove that an external claim is true, current or relevant to the organisation.

Potential duplicates should be linked for review rather than automatically dismissed. An asset lookup should return unknown or conflicting ownership when appropriate. A report concerning production cannot be verified solely from a submitted endpoint string or inventory match.

Keep model-generated summaries, detection-query ideas or severity suggestions separate from verified fields. This separation makes review and failure analysis clearer; it does not eliminate hallucinations or incorrect security conclusions. The same boundary matters when comparing n8n automation vs custom workflow software.

Handling Exceptions, Ambiguity, and Immutable Audit Trails

Define explicit states for insufficient evidence, unknown assets, conflicting sources, suspected duplicates and urgent review. Each state needs an owner, visibility and a manual path; “unparsed” must not silently become “invalid”. Escalation follows the organisation’s approved incident policy, not a keyword alone.

Record source references, parser and enrichment versions, material state changes and reviewer actions with appropriate access and retention controls. Append-only storage may support some audit requirements, but it is not automatically immutable, complete or compliant. Failed delivery needs a safe retry that avoids duplicate downstream work.

Estimate operating, review, security and recovery costs for the bounded workflow rather than only initial implementation, using the framework to calculate custom workflow software cost.

Preserving the Human Decision Gate

For this proposed workflow, automation must not publish a detection rule, deploy a patch, dismiss a disclosure or close an incident solely from extracted or generated content. The authorised security practitioner owns the decision and follows the organisation’s change and incident processes.

A review surface should distinguish the original evidence, retrieved internal context, unresolved conflicts and model suggestions. The reviewer can request more evidence, test a detection hypothesis in the approved environment, confirm or change classification, and route the next action within existing permissions.

Human review is a control to design and test, not a guarantee against false negatives. A pilot should measure reviewer corrections, missed context, failed routing and whether the resulting detection or remediation artefact passed its normal validation process.

Assessing the Internal Product Opportunity in Your Team

Map recent examples by source type and identify one recurring handoff where missing context or reformatting delays an authorised decision. Compare the current tools, supported connectors and ownership model before proposing a new internal product.

To discuss a first automation scope, describe one approved source, the artefact that should be produced, the reviewer and the recurring delay. Use sanitised examples without exploit instructions, credentials, customer records or private code. We can compare existing configuration with a limited integration and define permissions, evidence fields, exception handling, acceptance tests, monitoring, manual fallback and handover. The cited vacancies are not YAS client evidence or measured savings.

For a bounded evidence-to-decision workflow, YAS can compare existing configuration with a limited custom integration and document what your team would own after handover: custom software development company.

Checklist for an evidence-to-decision pilot

1. Choose one approved source type—such as a threat-intelligence feed or vulnerability disclosure—and document its required evidence and permitted use.
2. Measure time from receipt to the next authorised artefact, such as a detection-review record or verified remediation assignment.
3. Record missing evidence, unknown ownership, conflicting context and reviewer corrections rather than treating them as generic processing time.
4. Review suspected duplicates and record who linked or dismissed them and which evidence supported the decision.
5. List every manual transfer between source, evidence lookup, review and the existing engineering destination.
6. Check how detection changes or remediation tasks are tested, approved and rolled back today; do not create a parallel approval path by accident.
7. Define access, retention, source provenance, versioning, exception ownership, safe retry and manual fallback before connecting live security data.

Lead remediation of prioritized issues across our technology stack: collaborating with other engineers to triage and fix vulnerabilities discovered internally, through penetration testing, and through our bug bounty program