---
name: CCS Artifact Evaluation
slug: ccs-artifact-evaluation
category: Quality
description: CCS Artifact Evaluation helps package accepted security research artifacts for ACM badges and committee review. It covers reproducible setup, turnkey attack or defense demos, safe handling, and justifying withheld files.
github: "https://github.com/brycewang-stanford/Awesome-Journal-Skills/tree/main/ACM-CCS-Skills/skills/ccs-artifact-evaluation"
language: Stata
stars: 974
forks: 125
install: "npx degit https://github.com/brycewang-stanford/Awesome-Journal-Skills/tree/main/ACM-CCS-Skills/skills/ccs-artifact-evaluation ~/.claude/skills/ccs-artifact-evaluation"
installs_to: ~/.claude/skills/ccs-artifact-evaluation
source_path: ACM-CCS-Skills/skills/ccs-artifact-evaluation/SKILL.md
collection_size: 53
category_size: 1354
collection_url: "https://dirskills.com/collections/brycewang-stanford/Awesome-Journal-Skills"
added: 2026-08-12T04:43:36.579Z
last_synced: 2026-08-12T04:43:36.579Z
canonical_url: "https://dirskills.com/skills/ccs-artifact-evaluation"
---

# CCS Artifact Evaluation

CCS Artifact Evaluation helps package accepted security research artifacts for ACM badges and committee review. It covers reproducible setup, turnkey attack or defense demos, safe handling, and justifying withheld files.

**Install:**

```bash
npx degit https://github.com/brycewang-stanford/Awesome-Journal-Skills/tree/main/ACM-CCS-Skills/skills/ccs-artifact-evaluation ~/.claude/skills/ccs-artifact-evaluation
```

## README

# CCS Artifact Evaluation

Use this for artifact packaging around CCS. CCS runs an optional artifact-evaluation process
after acceptance; passing artifacts earn ACM badges that appear on the paper's first page.
Reopen the current call for artifacts for the exact badge set, submission form, and deadlines.

## The ACM badge ladder

| Badge | What it certifies | What the committee does |
|---|---|---|
| Artifacts Available | The artifact is publicly archived with a stable identifier | Confirms the artifact is retrievable and permanent |
| Artifacts Evaluated - Functional | The artifact runs and does what the paper says | Executes it against the documented steps |
| Artifacts Evaluated - Reusable | It exceeds functional quality and others can reuse it | Judges structure, documentation, and reusability |
| Results Reproduced | The main paper results are independently reproduced | Reruns experiments and checks they support the claims |

Available is about archival permanence; Functional and Reusable are about quality; Results
Reproduced is the highest bar and requires the committee to regenerate your headline numbers.

## Artifact plan

- Decide which claims the artifact must support: the exploit, the defense overhead, the
  measurement pipeline, or the protocol implementation.
- Make the security claim turnkey: one documented command per headline result, with expected
  output, runtime, and the hardware assumed.
- Anonymize nothing at this stage — artifact evaluation is post-acceptance and single-blind or
  open — but do pin versions, dependencies, and a container so it runs on a clean machine.
- For dangerous artifacts (working exploits, malware, live attack tooling), gate access,
  document safe-handling, and follow the responsible-disclosure posture from the paper.
- Justify anything withheld: licensing, disclosure embargo, subject safety, or premature-release
  risk, and offer partial, synthetic, or redacted substitutes that still let evaluators check
  the method.

## What security evaluators open first

| Claim type | First artifact inspected | Common failure caught |
|---|---|---|
| Exploit against real software | The PoC and its target build instructions | Target version unspecified; PoC fails to build |
| Defense with overhead numbers | The benchmark runner and instrumented build | Overhead cannot be reproduced; workload undocumented |
| Measurement study | The collection and classification scripts | Classification rule differs from the paper's prose |
| Cryptographic implementation | Test vectors and the reference build | No test vectors; outputs cannot be checked |

## Worked vignette: packaging a fuzzing-tool artifact

A hypothetical accepted paper presents a new fuzzer that found N bugs. For Reusable and
Results Reproduced: ship a container pinning the fuzzer, the target corpus, and the seed set;
document one command to reproduce a representative crash and one to rerun a bounded campaign;
provide the bug list with disclosure status; and note which crashes are embargoed pending
vendor patches, offering redacted reproducers for those.

## Output format

```text
[Target badges] available / functional / reusable / results-reproduced
[Contents] <code / data / container / test vectors / logs>
[Turnkey level] one-command / scripted / descriptive / weak
[Safe-handling] <gating and disclosure posture for dangerous artifacts>
[Withheld-and-justified] <what and why, with substitute offered>
[Fixes before submission] <ordered list>
```