usenixsec-related-work
GitHub指导在USENIX Security论文中撰写相关工作，覆盖四大安全会议及细分领域，处理多周期投稿下的最新文献检索与并发工作声明，强调通过威胁模型、规模或证据差异进行深度区分，并规范双盲引用自身工作的策略。
Trigger Scenarios
Install
npx skills add brycewang-stanford/Awesome-Journal-Skills --skill usenixsec-related-work -g -y
SKILL.md
Frontmatter
{
"name": "usenixsec-related-work",
"description": "Use when positioning a USENIX Security Symposium paper against prior work — covering the Big-Four security venues plus specialty conferences, handling concurrent submissions across the multi-cycle calendar, citing your own work double-blind, and using USENIX's open-access proceedings for verification."
}
USENIX Security Related Work
Related work at USENIX Security is an adversarial exercise: the committee contains people who wrote the nearest prior papers, and the multi-cycle Big-Four calendar means the nearest prior paper may be four months old. This skill covers coverage, differentiation, and the venue's citation mechanics.
The coverage map reviewers apply
| Lane | Where it lives | The question your text must answer |
|---|---|---|
| Big-Four security | USENIX Security, IEEE S&P, ACM CCS, NDSS | Same problem, same class of technique — what's new here? |
| Specialty security | PETS, SOUPS, RAID, ACSAC, WOOT, DIMVA, ESORICS | Did the niche community already do this at smaller scale? |
| Adjacent systems/ML | OSDI/SOSP, SIGCOMM/IMC, NeurIPS/ICML | Is the "security" contribution a re-badged systems or ML result? |
| Industry/offense track record | Black Hat/DEF CON talks, vendor blogs, CVE history | Do practitioners already know this? (Reviewers here often do) |
| Preprints and the cycle pipeline | arXiv, prior cycles' accepted-paper lists | What landed in the last 6–12 months that you must acknowledge? |
The fourth lane is distinctive: at this venue, an attack "known in the community" via a conference talk or advisory — even without an academic paper — weakens a novelty claim, and reviewers will cite the talk. Search offensive-industry sources, not just DBLP.
Freshness under a two-cycle regime
With USENIX Security itself, CCS, NDSS, and S&P all running multiple deadlines, the relevant literature refreshes roughly every quarter. Concretely:
- Sweep the accepted-papers pages of every Big-Four cycle that concluded after your last literature pass (e.g., a Sec '27 Cycle-1 submission in Aug 2026 should have digested Sec '26 Cycle-2 acceptances announced May 2026).
- USENIX helps you here: its proceedings are open access on usenix.org, so verification against the actual PDF costs nothing. Do the same via each venue's accepted-paper listings.
- Genuinely concurrent work (public after your submission, or within the same cycle window) merits acknowledgment, not differentiation-by-contortion. Reviewers know the calendar; say "concurrently and independently" and state the factual differences.
Differentiation that survives expert readers
Comparison tables of checkmarks read as advertising. The pattern that works here is mechanism-level: state what the prior system assumed or measured, then the delta. Three useful framings:
- Threat-model delta — "X defends against a network adversary; we handle a co-resident one, which breaks X's core assumption (shared cache is trusted)."
- Scale/vantage delta — "prior measurements covered one ccTLD from a single vantage; we cover 214 TLDs from 14 vantage points, and Section 6 shows the single-vantage view misestimates prevalence by 3×."
- Evidence delta — "Y's evaluation is simulation-only; we demonstrate the attack end-to-end on production hardware."
If the honest delta is "same idea, better engineering," consider whether the
contribution framing should change before the related-work section does (see
usenixsec-topic-selection).
Double-blind citation mechanics
Cite your own prior work in the third person as if written by strangers; the '26 CFP names first-person self-reference as an anonymity violation. When a paper builds so directly on your unpublished or just-published system that third person fails, the mitigation hierarchy is: cite an anonymized tech report in the artifact mirror; failing that, consult the chairs — never silently omit a paper reviewers will know exists, since a missing obvious citation both distorts positioning and fingerprints the authors.
@inproceedings{example-sec24,
author = {Doe, Jane and Roe, Riley},
title = {Sample: What a USENIX Security Reference Looks Like},
booktitle = {33rd USENIX Security Symposium (USENIX Security 24)},
year = {2024},
publisher = {USENIX Association},
url = {https://www.usenix.org/conference/usenixsecurity24/presentation/...}
}
Verify metadata against the usenix.org presentation page or DBLP's conf/uss
stream; both were consistent sources historically (DBLP direct fetch 403'd in this
environment on 2026-07-08 — cross-check via search rendering if needed).
Placement and length
Related work usually closes the body (≈1 page of the 13). Two exceptions worth making: an attack paper whose novelty hinges on a subtle difference from a known technique should differentiate early, in the introduction; SoK-style framing (if pursued at all — check the current CFP for whether the venue solicits it, 待核实) makes the literature the paper's subject rather than its perimeter.
Reverify each cycle
- Accepted-paper lists of all Big-Four cycles concluded since the last sweep.
- Whether the current CFP says anything about citing concurrent work or preprints.
- Anonymity wording around self-citation.
Output format
[Coverage] five lanes swept, with dates of the last sweep per lane
[Nearest neighbors] top 3–5 with mechanism-level deltas drafted
[Concurrent] same-window items + acknowledgment wording
[Self-citations] third-person rewrite check: pass / violations listed
Version History
- 9f86f09 Current 2026-07-19 17:52
