Conference Demos#

This page is for GitLab employees giving security-focused demos at conferences (RSA, BlackHat, AWS re:Invent, KubeCon, etc.). If you are setting this up for a customer demo on your own GitLab namespace, follow the lessons instead.

The conference demo is intentionally a static-scan-first demo. You can run the entire flow — pipeline, vulnerabilities, MR gates, dashboards, SBOM, Duo AI, compliance — without a Kubernetes cluster. DAST is the only feature that requires a running deployment, and it has a hosted alternative described below.

Prerequisites#

Open an issue at least 2 weeks before the conference at Developer Advocacy Team meta. Include every demo presenter who needs access. The Developer Advocacy team will:

1. Add team members to the conferences group
2. Set up the Tanuki Shop application with everything required to showcase GitLab security features
3. Set up the Tanuki Shop - Policies project
4. Set up the Tanuki Shop - Custom Pipelines

The setup includes:

1. Merge Request Approval Policy (Vulnerabilities)
2. Scan Execution Policy (IaC Scanning)
3. Pipeline Execution Policy (SOC2 + Secret Detection)
4. Merge Request with Vulnerabilities
5. The add-vulnerabilities source branch with a live MR

Running the demo without a cluster#

For conferences, don’t deploy to Kubernetes. The booth network is unreliable, your kubectl context is one VPN hiccup away from failing live, and DAST adds 3–5 minutes to every pipeline. Run the demo in this mode by default.

The demo environment is pre-provisioned with SKIP_DEPLOY=true set at the project level, so deploy-kubernetes and dast jobs are skipped automatically. Every other feature — SAST, Advanced SAST with code flow, dependency scanning, container scanning, secret detection, IaC scanning, policies, the vulnerability report, the SBOM, audit events, the compliance dashboard, and all Duo AI features — works without any change.

What to do about DAST in a no-cluster demo#

You have three options, in order of preference:

1. Skip DAST entirely. Most security conversations don’t require DAST and the rest of the platform is the bigger differentiator. Have a one-slide screenshot of a DAST result on hand for the “what about runtime?” question.

2. Use the pre-recorded DAST pipeline run linked from the demo bookmarks. The dast job’s findings already populate the vulnerability report on the default branch, so the rest of the demo behaves as if DAST ran.

3. Run the demo against an internet-reachable Tanuki Shop. A long-lived deployment lives at https://tanuki-shop-demo.gitlab-da.example (link in the conferences group’s pinned issue). Point the DAST scan profile’s site profile at it — no cluster setup required at the booth.

Standard Demo Flow#

Before launching into the script, sanity-check the attendee:

1. Are they currently using GitLab? If yes, what for?
2. What are they trying to solve from a DevSecOps perspective?

Use the answers to decide what to emphasize. If they just want to see the product:

Address questions as they come — don’t save them for the end. You should have a working understanding of GitLab Ultimate’s security and governance features so you can detour confidently when an attendee asks.

1. Pipeline-as-code with built-in scanners (~2 min)#

1. Open the .gitlab-ci.yml and walk through the include: block
2. Highlight: SAST, Dependency Scanning, Container Scanning, Secret Detection, and (in pre-recorded mode) DAST — all GitLab-maintained templates, no third-party glue code
3. Switch to the most recent pipeline view and point at the security stage
4. Note that the SOC 2 compliance job isn’t in the YAML — it’s injected by a pipeline execution policy. This is the separation of duties beat. Developers can’t remove it.

2. Merge request with vulnerabilities (~5 min)#

1. Open the live MR from the add-vulnerabilities branch
2. Show the Security scanning widget — multiple scanners, grouped findings
3. Click into a GitLab Advanced SAST finding and walk through Code flow (this is the wow moment — most competitors can’t trace data across files/functions)
4. Show the License Compliance widget with the denied licenses
5. Scroll to Approval required — explain that the MR is blocked by policy
6. Click Resolve with AI on one finding to demonstrate the AI fix MR (open it in a separate tab so you don’t lose your place)

3. Vulnerability report and triage (~3 min)#

1. Navigate to Secure > Vulnerability report
2. Show grouping by tool / severity
3. Open a vulnerability page
4. Walk through the risk assessment data: CVSS, EPSS, KEV badge, reachability — this is how teams prioritize
5. Click Explain with AI to show the contextual explanation
6. Demonstrate status transitions (Confirm, Dismiss with reason)

4. SBOM and continuous vulnerability scanning (~2 min)#

1. Navigate to Secure > Dependency list
2. Show the SBOM — components, licenses, locations
3. Mention CycloneDX export for handoff to auditors and procurement
4. Point at Continuous Vulnerability Scanning in Settings > Security and compliance — new CVEs against shipped dependencies appear without a code change

5. Audit events (~1 min)#

1. Navigate to Secure > Audit events
2. Show the timeline: policy changes, vulnerability dismissals, role changes — tamper-proof, streamable to a SIEM

6. Compliance center and frameworks (~3 min)#

1. Navigate to the group’s Secure > Compliance center
2. Open the Frameworks tab and show the Tanuki AppSec Baseline framework
3. Click into it to show the requirements/controls structure
4. Open the Projects tab and show the per-project adherence percentage
5. Mention the 50+ out-of-the-box controls and SOC 2 / ISO 27001 / NIST 800-53 / FedRAMP templates

7. Close (~1 min)#

Pick the part the attendee reacted to and reinforce it:

• “They cared about MR-time gates” → recap policies + separation of duties
• “They cared about triage cost” → recap risk assessment + Duo Explain/Resolve
• “They cared about scale” → recap compliance frameworks + group-level policies

If you don’t remember how to perform one of these steps, every screen is covered in the lessons — open the relevant lesson page on your tablet/laptop in a separate window before the demo.

Self-hosting the demo on a laptop#

If you can’t reach the pre-provisioned demo environment (no internet, restricted booth, secondary demo), the entire static-scan demo runs on your laptop with no cloud resources at all.

Prerequisites#

• Docker Desktop (or Rancher Desktop / OrbStack)
• Git
• ~4 GB free disk space
• A GitLab.com account with an Ultimate trial activated

Steps#

1. Import the Tanuki Shop project into your own namespace (see Lesson 1)

2. In your project’s Settings > CI/CD > Variables, add:

3. Push a commit (or run a pipeline from the web UI) — the security stage runs, deploy and DAST are skipped

4. Run the application locally if you want a UI to point at:

git clone https://gitlab.com/gitlab-da/tutorials/security-and-governance/tanuki-shop.git
cd tanuki-shop
docker build -t tanuki-shop .
docker run -p 3000:3000 tanuki-shop

5. Open http://localhost:3000 — this is just the storefront. None of the GitLab security features depend on it; it’s there so you can show what the app actually looks like.

Pre-pull the demo browser tabs#

Before stepping into the booth, open and pin these tabs in order. They cover the entire flow without any clicks more than one level deep:

1. The Tanuki Shop project home
2. The .gitlab-ci.yml view
3. The latest pipeline
4. The add-vulnerabilities merge request
5. The vulnerability report
6. A specific Advanced SAST vulnerability with code flow visible
7. The dependency list (SBOM)
8. The audit events page
9. The group’s compliance center
10. localhost:3000 (or the storefront URL) — last, so you can show what the app actually does

This ordering matches the standard flow above, so you can demo by pressing Cmd/Ctrl+Tab.

Troubleshooting#