GitLab Security Specialist common mistakes
GitLab Security Specialist · Understand the traps and how to avoid them.
When asked how to make a pipeline fail on a newly detected critical vulnerability, the candidate answers that setting the scanner to 'enabled' is sufficient and does not configure any failure threshold or merge-request approval rule.
Candidates conflate 'scanning runs' with 'scanning gates'. GitLab security scanners report findings by default but do not block; blocking requires explicit policy (e.g., merge request approval policies or a CI job rule that fails on severity). The exam repeatedly tests the difference between detection and enforcement.
What to do instead
Memorise the enforcement chain: scanner produces a report artifact, the report feeds the security approval policy or a job-level severity check, and the policy blocks the merge. Be able to state which severity threshold is configured where, and that approval policies are evaluated at merge-request time rather than only in the pipeline.
The candidate treats every security scanner as if it required the same setup, claiming SAST, DAST, and dependency scanning all need a running deployed environment and a URL.
The scanners have genuinely different prerequisites: DAST needs a target URL and a reachable environment, while SAST and dependency scanning operate on source and lockfiles. Candidates who memorise 'security testing' as one blob misassign prerequisites.
What to do instead
Build a comparison table from memory: input (source code, lockfile/manifest, running app URL, container image, IaC files), when it runs (commit, merge request, pipeline schedule), and what artifact it produces. Rehearse matching a scenario to the correct scanner before touching configuration details.
When asked to reduce false positives, the candidate proposes disabling the scanner entirely or lowering all severity thresholds, instead of using the tooling designed for triage.
Candidates reach for the bluntest lever because they have not internalised the triage features: vulnerability dismissal with reasons, scanner rule exclusions, and per-project configuration files. The exam frames false positives as a governance problem, not a scanning problem.
What to do instead
Learn the triage toolkit and when each applies: dismiss a finding with a documented reason, exclude a specific rule or path in the scanner configuration, and adjust severity thresholds only at the policy layer. For each, be able to say who can perform it and whether it is auditable.
The candidate describes compliance frameworks as a dashboard that reports status, and cannot explain that controls must be linked to evidence and that a framework can be scoped to projects.
Compliance features are often skimmed because they look like reporting. In reality the exam tests the data model: a framework contains requirements, requirements map to controls, and controls are satisfied by evidence from pipelines or external sources. Without that model, answers collapse into vague 'monitor compliance' statements.
What to do instead
Draw the hierarchy from memory: framework → requirement → control → evidence. Then practise explaining how a project is attached to a framework and how a failing control is surfaced. Distinguish compliance posture reporting from the enforcement mechanisms that actually prevent non-compliant changes.
When a question asks how to guarantee a protected branch cannot receive a non-compliant merge, the candidate lists approval rules but omits that the rule must be scoped to the branch and that settings can be pushed down to all projects.
Candidates know approval rules exist but not their scoping and inheritance. They answer at the project level when the exam is testing group-level or instance-level enforcement, or vice versa.
What to do instead
For each governance control, be able to state its scope (instance, group, project), whether it can be enforced centrally, and what happens to projects that already have local settings. Practise the phrase 'enforced at the top level, inherited below' and identify which controls support it.
The candidate treats audit events as a complete record of everything that happened and claims any action can be retrieved, rather than knowing that audit event coverage depends on tier and on which event types are recorded.
Audit logging is assumed to be exhaustive. The exam tests whether the candidate knows that some events are only available at higher tiers, that streaming to an external destination is a separate capability, and that retention differs from application logs.
What to do instead
Separate three concepts: which events are recorded, where they are stored (local vs streamed externally), and how long they are retained. Be able to say what to do when a required event is not captured locally - namely stream audit events to an external system - and note that this depends on the tier.
The candidate stores a secret as a masked CI/CD variable and asserts that masking makes the value safe, without addressing that masked variables are still visible to anyone who can edit the project and can leak through logs if the format is not maskable.
Masking is misunderstood as encryption. Masking only prevents the literal string from appearing in job logs; it does not restrict who can read the variable, and values that do not meet masking requirements cannot be masked at all.
What to do instead
Distinguish protected variables (only exposed to pipelines on protected branches or tags), masked variables (log redaction only), and an external secrets manager (value never stored in the project). For a scenario asking to keep a production credential away from feature branches, the answer is a protected variable or external secret, not masking.
The candidate proposes committing an encrypted secrets file or a sealed-secret manifest into the repository and calls that secrets management, without explaining how the decryption key is delivered to the pipeline.
This is a plausible-sounding pattern that fails the core test: the key must itself be a secret. Candidates who have not thought through key distribution give an answer that just moves the problem.
What to do instead
Always trace the chain to its root. For any secrets proposal, ask 'where does the decryption key or credential come from, and who can read it?' If the answer is a CI/CD variable, state whether it is protected and masked, and whether the job runs on a protected branch. If an external vault is used, explain the authentication step (e.g., identity token exchanged for a short-lived credential).
The candidate answers supply chain questions by describing dependency scanning alone and omits artifact integrity controls such as signed container images, the dependency proxy, and lockfile enforcement.
Supply chain security is reduced to 'scan dependencies'. The exam also tests provenance and integrity: whether the image that reaches production is the one that was built and scanned, and whether dependency sources are pinned and proxied.
What to do instead
Structure supply chain answers in three layers: what enters (dependency scanning, lockfile pinning, dependency proxy), what is produced (container scanning, image signing, attestation), and what is admitted (verification before deploy). Be able to say which layer a given control belongs to and what gap remains if it is missing.
When asked to measure whether the security programme is improving, the candidate cites the number of vulnerabilities found or the number of scans run, rather than a metric tied to remediation behaviour.
Volume metrics are easy to produce and feel like progress, but more findings or more scans says nothing about risk reduction. The exam tests whether the candidate can choose a metric with a denominator and a time dimension.
What to do instead
Prefer metrics that combine severity, time, and population: median time to remediate by severity, percentage of critical findings remediated within a target window, or the proportion of projects with security scanning enabled. For each metric, be able to state the numerator, the denominator, and the decision it informs.