• Modern systems are too large and fast-moving for purely manual auditing.
• Traditional static and dynamic analysis can be powerful, but often hits hard limits in precision, scalability, and engineering cost.
• AI can help, but it can also hallucinate, lose grounding, or generalize poorly.
• The most promising direction is combining AI with strong program representations and measurable evaluation.

This course is designed to teach two things simultaneously:

1. AI for software security (what works, what does not, and how to make it work better)
2. Real-world engineering collaboration (how teams build tools together in a shared repo)

Components

• Early instructor-led lectures (first two weeks): Shared foundations on traditional security analysis challenges, AI challenges, and how to combine them.
• AuditZoo architecture session (end of week 2): A guided tour so everyone builds on a common substrate.
• Student paper presentations (starting week 3): Each presentation is 20 minutes plus 10 minutes Q&A.
• Semester-long project (teams of 1-3): Build an auditor (recommended) or extend AuditZoo itself.
• AuditZoo updates + Q&A (weekly): We track infrastructure progress and unblock contributors.
• Industry talks (up to 4 total): Practitioners share how AI4Sec works in production and where the hard problems are.

Guest talks may shift; three sessions are reserved as "Guest talk / flexible slot" dates.

• Python programming.
• Basic understanding of program analysis: control flow graph, data flow graph, taint analysis, and related concepts.
• Git and GitHub.

We use GitHub as the system of record for coordination, collaboration, and communication. Please read the GitHub guide and check the private repo updates and discussions.

• Strengths and limitations of static, dynamic, and symbolic analysis, and where they break down in practice.
• How to design AI-assisted auditors that use program structure to ground decisions in evidence.
• How to turn a research idea into an implementable approach with scope, threat model, and failure modes.
• How to evaluate a security tool rigorously with metrics, test cases, and honest limitations.
• How to work like an engineering team in a shared repository with PRs and integration discipline.
• How to communicate technical work through paper talks, proposals, progress updates, and final presentations.

All projects live in a shared private AuditZoo repository during the semester. Teams choose one of two tracks.

Track A (strongly recommended): Auditor projects

Build an AI auditor agent specialized for one vulnerability class or defect pattern.

Examples:

• Find SQL injection in a Python web app backed by PostgreSQL or MySQL.
• Find authorization bypass or insecure direct object reference in a React-based admin dashboard.
• Find command injection in CI/CD scripts or deployment pipelines.
• Find path traversal and unsafe file handling in a document processing service.
• Find SSRF patterns in a cloud-integrated service (metadata or internal API access).
• Find unsafe deserialization in Java or Kotlin microservices.
• Find access-control or reentrancy bugs in Ethereum smart contracts.
• Find Inconsistent specification-to-code mapping in go-ethereum (geth) or other Ethereum clients.

Expectations:

• A working auditor integrated into AuditZoo so others can run it
• Clear output format with findings and evidence
• An evaluation section in the final report

You are also welcome to re-implement a published paper or existing method and integrate it into AuditZoo with a clean evaluation.

Track B: AuditZoo infrastructure projects

Extend the framework itself.

Examples:

• Add a CodeQL backend or strengthen existing integrations
• Add tree-sitter-based parsing to support more languages (e.g., Ada)
• Extend program abstraction layers with new graph queries or IR adapters
• Improve scalability and automation (documentation and unit tests) that enables Track A auditors

Expectations:

• A working infrastructure feature integrated into AuditZoo
• A small demonstration auditor or example showing why the feature matters
• An evaluation of what capability it enables and what constraints remain
• More frequent PR merges to keep in sync with main (Track B touches core infrastructure)

Students are welcome to open issues on the current framework in the corresponding private repo. We will keep a small set of issue templates to keep triage fast:

• Feature Request
• Bug Report
• Integration or Build Help

To motivate real impact, the course includes a bug bounty program and an all-time leaderboard. Each unique vulnerability that is confirmed by the project developer or maintainer earns +1 extra course point.

• The target must be a well-known project or a repository with at least 1000 GitHub stars.
• Points are shared across team members.
• If multiple groups report the same bug independently, the point is split evenly.
• No cap on extra points; we will maintain a course leaderboard.

That means, if a student reaches 100 maintainer-confirmed vulnerabilities, the student may skip all presentation and proposal requirements. Students should follow each project's security policy and responsible disclosure norms.

See the bug bounty leaderboard for current standings.

Paper presentations

• 20 minutes presentation plus 10 minutes Q&A.
• Students choose papers within scope and sign up for dates in GitHub Discussions (first-come-first-confirm-first-in).
• We will also provide a list of papers that do not require instructor confirmation.

Project presentations

• Midterm proposal presentation: 10 minutes per team.
• Final presentation: 20-30 minutes, demo encouraged.

Anonymous rating (1-10)

For every presentation, the audience submits an anonymous 1-10 rating with optional written feedback. These ratings provide structured feedback and contribute to presentation scoring in a controlled way, with normalization to reduce popularity bias.

• Attendance: 5% (light-touch; at most one attendance check if needed).
• Paper presentation (individual): 15%.
• Project proposal (team): 10% (1-2 pages, IEEE S&P format; see IEEE S&P author guidelines.
• Midterm proposal presentation (team): 10%.
• Final project presentation (team): 20%.
• Final report + evaluation (team): 40%.
• Bug bounty: uncapped extra points (maintainer-confirmed only).

• Each team has 2 guaranteed late days for written deliverables.
• Late days do not apply to scheduled presentations.
• Beyond that, we will be flexible as long as it does not disrupt scheduling and coordination.

• AuditZoo (course framework).
• AutoGen (agent framework reference).
• Joern (code property graph platform).
• GitHub in this course.
• Bug bounty leaderboard.

All deadlines are 11:59 PM unless noted.

Meeting time: Tue/Thu 5:40-6:55 PM. Location: 601B Sherman Fairchild Life Sciences Building. Guest talks may shift; flexible slots are used for paper presentations or project Q&A.

Lecture Paper Project Guest Flexible Q&A Deadline

Midterm proposal presentations: 10 minutes per team.