Logseq/Entity/Security/Vuln

• Security Vulnerability

  • In this garden, Security Vulnerability pages model a vulnerability, exploit class, attack technique, attack chain, or defensive-relevant abuse pattern.

  • Examples in this garden

    • Security/Attack/Chain/Supply
    • Security/Vulnerability
    • AI/Security/Attack/Agentic/Tool Chain/Poisoning
    • AI Coding/Security/Slop Squatting
    • Man in the Middle Attack

  • When we treat something as a Security/Vuln entity

    • Strong signals: the page describes how a system can be attacked, how a weakness can be exploited, how an adversary gets leverage, or how defenders should recognize and reduce that attack path.
    • Good fit: CVE/GHSA/CWE-centered notes, exploit classes, named attack techniques, attack chains, post-exploitation patterns, insecure defaults, dependency or tool-distribution risks, and attacker-controlled workflow abuse.
    • Prefer Logseq/Entity/Concept when the page is mainly an explanatory lens or broad security idea rather than a concrete attackable weakness or technique.
    • Prefer Logseq/Entity/Term when the page is only a short glossary definition and does not need attack mechanics, defender relevance, or related controls.
    • Prefer Logseq/Entity/Software/Project when the page's primary identity is a tool, library, application, scanner, framework, or platform, even if the tool is security-related.
    • Existing concept or term pages can remain as-is until they are intentionally migrated; new or materially revised pages should use this type when the vulnerability or attack path is the page's primary identity.

  • Finding and deduplicating

    • Search for an existing page before creating a new Security/Vuln entity.
    • Search order hints: exact title, aliases, security namespace siblings, normalized attack names, CVE identifiers, GHSA identifiers, CWE identifiers, vendor advisory names, and page-body mentions of the same exploit path.
    • Treat two pages as likely duplicates when they describe the same weakness or attack path, even if one is named for the vulnerability and another is named for an attacker workflow.
    • Treat pages as related but distinct when one is a general class and another is a specific incident, product vulnerability, or implementation example.
    • Classify as: existing, similar, new, or blocked.

  • Frontmatter

    • On instances, set logseq-entity:: to Logseq/Entity/Security/Vuln so backlinks list all vulnerability and attack-pattern entities.
    • Preserve existing tags:: frontmatter exactly when revising legacy pages.
    • Shared frontmatter conventions live on Logseq/Frontmatter.

  • Page shape

    • Use Logseq Flavored Markdown.
    • First block after frontmatter: H1 matching the primary attack, vulnerability, or weakness name.
    • Start with a concise description of what the attack or weakness is.
    • Useful sections include Mechanism, Where it appears, Defender relevance, Examples, Misconceptions, and Related. Adapt headings to the note; short pages do not need every section.
    • For named identifiers, include CVE, GHSA, or CWE links when they are central to the page identity. Aliases for them are added only when codekiln asks, per My/AI/Rule/Logseq/No Aliases Unless Asked.
    • Link to defensive tooling or control pages when they clarify how the risk is found, mitigated, or monitored.