Use automatic analysis when you need fast, low-friction feedback with minimal setup and mainly want continuous checks on supported repositories. Move to CI-based analysis when you need deeper dependency resolution, code coverage reporting, branch-specific control, monorepo support, or tighter tuning of build resources. The right choice depends on whether speed of adoption or depth of analysis is the primary goal.
What the analysis choice is really optimising for
For GitLab projects, the decision is less about which analysis mode is “better” and more about which operating model you need to support. Automatic analysis reduces setup friction and gives teams a quick, always-on baseline. CI-based analysis gives you more control over when analysis runs, what build context it sees, and how deeply the scanner can interpret the project.
The practical trade-off is adoption speed versus fidelity. Automatic analysis is usually easiest to roll out across many repositories, especially when you want consistent checks without asking each team to wire security into their pipeline. CI-based analysis is the better fit when the repository structure, build process, or dependency graph is too complex for a lightweight default scan.
That distinction matters because analysis quality is not only about finding more issues, it is also about whether the tool sees the same inputs your build and release process uses. If security signals are missing source sets, generated files, or branch-specific dependencies, the output can look clean while still being operationally incomplete.
When to prefer automatic analysis, and when to move to CI-based analysis
Automatic analysis is a strong default when teams need fast coverage with minimal operational overhead. It works best for standard repositories where the main goal is to surface obvious dependency or code issues early, and where the organisation values broad adoption more than environment-specific tuning.
CI-based analysis becomes the better option once the project needs more than a generic scan. Common triggers include monorepos, build-time dependency resolution, code coverage reporting, branch-aware controls, or the need to allocate more time and resources to analysis jobs. In those cases, the pipeline is not just a delivery mechanism, it is part of the analysis context.
If your team is deciding between the two, the most useful question is whether the repository can be analysed accurately without the build steps that normally produce the application artefacts. If the answer is no, CI-based analysis is usually the safer operational choice because it aligns security checks with the same inputs developers actually ship.
- Choose automatic analysis for broad rollout, low-friction onboarding, and simple repository structures.
- Choose CI-based analysis when you need build context, branch control, coverage signals, or more precise resource tuning.
- Reassess if the default scan misses generated code, module resolution, or other build-time dependencies.
Risk and Threat Considerations
Analysis mode can change the quality of security visibility, which makes this an operational risk decision as much as a tooling choice. If teams rely on a lightweight scan for repositories that actually depend on complex build logic, they can get false confidence from incomplete results, especially in projects with shared modules, hidden dependencies, or multiple release branches.
Failure mechanism: The scanner runs without the same dependency resolution or build context that the application uses, so vulnerable packages, mis-scoped branches, or coverage gaps are not represented in the findings.
Impact: Issues may remain undetected until later in the delivery cycle, which weakens prioritisation, slows remediation, and can allow insecure code or dependencies to reach production with less scrutiny.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 2.1 — Inventory and Control of Enterprise Assets | Repository analysis choice depends on knowing which projects need baseline vs pipeline-driven scanning. |
| CIS 4.1 — Establish and Maintain a Secure Configuration Process | CI-based analysis is a configuration choice that shapes how security checks run and what they inspect. | |
| CIS 16.6 — Automated Software Integrity Verification | Both analysis modes are integrity checks on code and dependencies within the software delivery flow. | |
| Recommendation — Classify GitLab projects by build and release criticality before standardising the analysis mode. Document and enforce the pipeline configuration used for security analysis. Use automated verification in the delivery pipeline when repository context affects security findings. | ||
| NIST CSF 2.0 | DE.CM-8 — Vulnerabilities are monitored through continuous assessments | The choice determines how continuously and how deeply repositories are assessed for issues. |
| PR.DS-6 — Integrity checking mechanisms are used to verify software, firmware, and information integrity | Analysis mode affects how well security tooling can verify the integrity of software inputs and outputs. | |
| Recommendation — Tune repository scanning cadence and depth to match the project’s risk and complexity. Ensure the chosen scan path can verify the same software inputs the build consumes. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Secrets and Credential Management | GitLab project analysis can expose secrets embedded in code or pipelines, which is a core NHI concern. |
| NHI-08 — Third-Party and Supply Chain Risk | CI-based analysis is often needed when dependency resolution and pipeline context drive supply-chain exposure. | |
| NHI-09 — Visibility and Discovery | The question is fundamentally about how teams get the right visibility into project security posture. | |
| Recommendation — Scan the full delivery path when secrets may be stored in code, config, or CI variables. Use pipeline-aware analysis for repositories with shared dependencies or supply-chain-sensitive builds. Prefer the analysis mode that best exposes the project’s real dependency and branch context. | ||
Practitioner Guidance
What to verify: Test the chosen mode against one representative repository before standardising it. Confirm whether the scan sees the same dependency tree, branch context, and generated artefacts that the build process uses, because that is where analysis quality usually breaks down.
Decision rule: If the repository can be analysed accurately without build-time context, start with automatic analysis for speed and consistency. If analysis quality depends on pipeline inputs, shared modules, or branch-specific behaviour, move to CI-based analysis rather than trying to compensate with policy alone.
What good looks like: Teams can explain why a repository is on automatic analysis or CI-based analysis, and that choice matches the project’s structure instead of being inherited by default. The best signal is not simply “a scan is running,” but “the scan is seeing the same code and dependencies the release process will ship.”
Practitioner takeaway: Use automatic analysis for reach, but treat CI-based analysis as the control that restores fidelity when the repository’s real build context matters more than convenience.
Related resources from NHI Mgmt Group
- How should security teams decide between certificate-based authentication and MFA?
- How should security teams choose between semantic code analysis and AST-based scanning?
- How should teams decide between token-based and flat-fee security testing?
- How do security teams decide whether to use token-based or identity provider based access for GitLab integrations?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
