技能 编程开发 USENIX安全会议相关工作撰写指南

USENIX安全会议相关工作撰写指南

v20260724
usenixsec-related-work
本指南为作者提供了在顶级安全会议(如USENIX Security)撰写“相关工作”部分的专业指导。内容涵盖了如何构建领域覆盖图谱、确保研究工作在新颖性上的定位、处理多周期文献更新,并掌握专家级的引用和差异化表达技巧。
获取技能
298 次下载
概览

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:

  1. 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)."
  2. 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×."
  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
信息
Category 编程开发
Name usenixsec-related-work
版本 v20260724
大小 5.52KB
更新时间 2026-07-29
语言