sec-conf-write

name

sec-conf-write

description

Security conference paper writing, rewriting, outlining, and reviewer-style critique for ACM CCS, NDSS, IEEE S&P, and USENIX Security. Use when Codex needs to draft or revise security paper abstracts, introductions, threat models, vulnerability definitions, empirical-study sections, methods, evaluations, security impact, responsible disclosure, ethics, artifacts, rebuttals, or pre-submission checks. Also use when a user asks for top-tier security conference writing guidance, section blueprints, reviewer expectations, or venue-aware paper positioning.

Security Conference Writing

Use this skill to turn security research material into a clear top-tier security paper narrative. Optimize for papers where the central contribution is a security failure mode, attacker model, defense, analysis, measurement, exploit technique, or security-relevant empirical finding.

Do not use this skill for standalone CVE advisories, pentest reports, exploit writeups, or vulnerability reports unless the user explicitly wants to reframe them as a research-paper contribution.

Default Workflow

1. Classify the request: new draft, section rewrite, outline, reviewer critique, rebuttal, venue positioning, or checklist pass.
2. Identify the paper archetype: vulnerability class, detection or analysis tool, defense or mitigation, attack, measurement study, SoK or taxonomy, usable security, or privacy.
3. Build the security narrative before editing prose:

Security problem:
Attacker:
Protected asset:
Security property:
Root cause:
Key observation:
Approach:
Evidence:
Impact/disclosure:

4. Load only the relevant reference file from references/.
5. Draft, rewrite, or review section by section.
6. Check the result as a security reviewer: realism of attacker model, clarity of the invariant, novelty against prior work, fairness of baselines, validity of evidence, limitations, ethics, disclosure, and artifact claims.

Ask for missing technical details when attacker capability, protected asset, vulnerability condition, dataset, evaluation result, or disclosure status cannot be inferred from the supplied material.

Narrative Thesis

Every security paper should reduce to:

We identify [security failure mode] in [real setting], show that it arises because [root cause], and build [approach] that [detects/prevents/measures] it by [key insight], finding [real-world impact].

If this sentence cannot be filled, first stabilize the technical claim instead of polishing the prose.

Reference Selection

• Read references/sec_writing_patterns.md for overall security-paper philosophy, contribution shapes, reusable prompts, and common mistakes.
• Read references/storytelling-patterns.md when the paper has material but needs a dominant narrative or when choosing between vulnerability-class, tool, defense, and measurement/SoK stories.
• Read references/sec-section-blueprint.md for paragraph-level drafting or rewriting of titles, abstracts, introductions, threat models, empirical studies, methods, evaluations, related work, ethics, and conclusions.
• Read references/sec-checklist.md for a pre-submission quality pass.
• Read references/sec-reviewer-guideline.md for reviewer-style critique, likely objections, score drivers, and rebuttal preparation.
• Read references/sec-conferences.md for venue-specific positioning, deadlines, page limits, and review-process context.

Venue policies, deadlines, page limits, AI policies, artifact rules, and ethics requirements change. When the user asks for current or submission-critical venue details, verify against the official CFP before giving final guidance.

Section Order

Use this default order unless the draft or venue requires another structure:

Title
Abstract
1 Introduction
2 Background and Problem Statement
3 Threat Model and Vulnerability Definition
4 Empirical Study / Motivation
5 Approach / Design
6 Implementation
7 Evaluation
8 Security Impact / Case Studies
9 Discussion / Limitations
10 Related Work
11 Ethics and Responsible Disclosure
12 Conclusion
Appendices: Artifact, Open Science, Proofs, Extra Results

The invariant matters more than the section names: define the security problem before selling the system.

Drafting Rules

• Start with the specific security mechanism and failure mode, not broad generic context.
• State the attacker, capability, limitation, protected asset, and violated property explicitly.
• Define vulnerability classes as invariant failures.
• Connect empirical findings to method design; each finding should motivate a design choice or evaluation question.
• Separate alerts, manually confirmed bugs, fixes, CVEs, exploitability evidence, and pending disclosures.
• Report precision, recall, false positives, false negatives, baselines, ablations, overhead, compatibility, and scalability when relevant.
• Discuss limitations honestly and technically.
• Do not fabricate citations, venue rules, CVEs, disclosure outcomes, datasets, implementation details, or experimental results.
• Mark unknown citations or claims as [CITATION NEEDED] or [RESULT NEEDED] instead of inventing them.

Reviewer Check

Before returning a major rewrite or review, check:

• Is the security property obvious by the end of the abstract?
• Is the attacker model realistic and narrow enough to evaluate?
• Is the vulnerability class distinct from prior work?
• Does the approach follow naturally from the root cause or empirical findings?
• Are baselines strong and fairly configured?
• Are false positives, false negatives, and validation protocols explained?
• Are ethics, responsible disclosure, and artifacts handled responsibly?
• Are claims backed by actual evidence rather than rhetorical novelty?