Security Labs
Research and engineering behind Onion’s services and products
Security Labs is Onion Infosec’s research and engineering function. It studies questions raised by service delivery and product design, and turns the answers into detections, test methods and tooling that go back into both.
- Function
- Research and security engineering
- Areas
- 5 standing research areas
- Feeds
- Services, detection content, products
- Publishing
- First research notes in progress
01Research register
Five areas of standing work.
- LAB/01
Threat Research
Study of intrusion techniques and the telemetry they leave, so that detection and response work starts from evidence.
- LAB/02
AI Security
Research into how AI systems fail under attack, how to test them repeatably and how to evaluate AI used in security work.
- LAB/03
Detection Engineering
Detection content built, tested and maintained as software, with coverage reported as it is and not as it is mapped.
- LAB/04
Security Automation
Research and engineering on which security work can be automated safely, and how to keep automation auditable and reversible.
- LAB/05
Vulnerability Research
Study of recurring flaw classes in applications, components and boundary devices, handled under coordinated disclosure.
02Purpose
An engineering function, not a content channel.
Labs works in five areas: threat research, AI security, detection engineering, security automation and vulnerability research. Each area keeps a short list of open questions, a defined method and a named type of output. Work counts as finished when a service team or a product team can use the result.
Two engineering practices carry research into use. Security engineering builds the tooling, detection content and test methods that service teams work with. Product innovation takes ideas that hold up in the lab into XDR, GRC and the Autonomous SOC Analyst L1 & L2. Labs has not published research yet. Output will appear on the research page as it is released.
03Path
From delivery work to research, and back.
01 · Services → Security Labs
Delivery work raises questions: a technique that no detection covers, an investigation step that should be automated, a class of flaw that tools miss.
02 · Security Labs → Services
Labs researches the question in a controlled environment. Security engineering turns what holds up into detection content, test methods and tooling for the teams delivering security operations, offensive security, AI and cloud work.
03 · Security Labs → Products
Product innovation takes ideas that hold up in testing into XDR, GRC and the Autonomous SOC Analyst as design requirements, detection content and components.
04 · Products → Security Labs
Product design raises its own questions, such as how to evaluate an AI system that investigates alerts. These return to Labs as research.
04Method
How research is done here.
- Questions come from the work
- Research starts from a question raised in service delivery or product design: a technique with no detection, an investigation step that should be automated, a class of flaw that scanners miss. Topics are not chosen for publicity value.
- Reproducible by design
- Lab environments, test data and procedures are recorded so that another engineer can repeat the work and reach the same result. Claims are limited to what the evidence supports, and confidence is stated.
- Research ends in engineering
- A finding is complete when it has become something usable: a tested detection, a test method, a tool or a requirement in a product backlog. Security engineering and product innovation sit inside Labs for that reason.
- Publish with care
- Work is published when it helps defenders and after affected parties have had time to act. Vulnerabilities follow coordinated disclosure. Confidential information from an engagement is never included.
05Outputs
What Labs publishes.
Vulnerabilities that Labs finds in third-party software or hardware are reported privately to the vendor or maintainer, with enough technical detail to reproduce the issue. Publication follows a fix or an agreed timeline, and a national CERT or other coordinator is involved where that helps. To report a vulnerability in Onion Infosec’s own systems, see the vulnerability disclosure policy.
- Research note
- A technical write-up of one question: what was tested, how, what was found and what a defender can do with it. Written so that the work can be repeated.
- Advisory
- A short notice on a vulnerability or an active technique, with affected versions or conditions, detection guidance and mitigation. Vulnerability advisories are released under coordinated disclosure.
- Tool
- Source code for a utility built during research, such as a test harness, parser or collector, released with documentation when it is useful outside Onion.
- Talk
- A conference or community presentation of completed research, with slides and supporting material published afterward.
- Detection content
- Detection rules and queries with the test data, MITRE ATT&CK mapping and tuning notes needed to run them. The same content is used in our security operations service and in XDR development.