OpenHands / OpenHands/software-agent-sdk
Proposal: extend defense_in_depth PatternSecurityAnalyzer with Agent Threat Rules signatures
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 1.1k
- Forks
- 539
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 137
Description
The defense_in_depth module already ships a strong PatternSecurityAnalyzer with stable detector IDs and a careful two-corpus design that separates executable scanning from all-field scanning. The existing pattern set covers rm -rf, sudo rm, mkfs, dd, eval/exec/os.system/subprocess, curl-pipe-sh and wget-pipe-sh, and a small injection family. This is exactly the right shape for a maintained rule set.
I would like to propose extending the pattern coverage by mapping in detection signatures from the open Agent Threat Rules project at https://github.com/Agent-Threat-Rule/agent-threat-rules. ATR is Apache-2.0 and ships 330 rules across 9 categories with explicit MITRE ATLAS and OWASP Agentic Top 10 mappings. The same rule pack has shipped at Cisco AI Defense skill-scanner and Microsoft agent-governance-toolkit, so it is reasonable to consider as upstream rather than reinvent.
The integration is small and additive. I am proposing a new ATRPatternSet helper that loads a curated subset of ATR YAML rules at import time, converts them to the existing (regex_pattern, description, detector_id) tuple format, and merges them into DEFAULT_HIGH_PATTERNS / DEFAULT_MEDIUM_PATTERNS. Detector IDs would be prefixed atr.* to keep them visually distinct from the native exec.* and inject.* IDs you already use. No new runtime dependency. Pure Python, regex only, no network, no model inference. The patch would be under 150 lines plus tests.
Before I send a PR I want to check three things with maintainers. First, is the PatternSecurityAnalyzer pattern table the right place to add upstream-curated rules, or would you prefer a sibling analyzer that keeps the native and ATR rule sets isolated? Second, do you want ATR shipped as a vendored Python module (one-time copy of selected patterns with attribution comments) or as an optional install-time fetch from the ATR repo? My default would be vendored with comments pointing to upstream rule IDs so review is fully local. Third, are there detector ID naming conventions or telemetry contracts I should preserve so downstream consumers do not regress.
Happy to send a small initial PR with 5 to 10 high-precision patterns from ATR categories that do not overlap with what is already in pattern.py, focused on prompt injection variants, exfiltration domains, and credential leakage. License is Apache-2.0 on both sides, so attribution is the only requirement.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading pattern.py and the existing PatternSecurityAnalyzer, including DEFAULT_HIGH_PATTERNS, DEFAULT_MEDIUM_PATTERNS, detector IDs, and the two-corpus design. Review the proposed Agent Threat Rules YAML source and maintainer decisions about isolation, vendoring, attribution, and naming; done means an agreed 5–10-pattern integration with tests and preserved downstream contracts.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100