Enable IaC security scanning as an opt-in decision
DRI: @rossfuhrman
---
As a customer, I want the ability within GitLab to perform security scans on Infrastructure as Code (IaC) files.
Security scanning for IaC is somewhat different from SAST for programming languages in that IaC tools utilize files that are, fundamentally, configuration files. These files are used to provision assets in a third-party location that will host assets, making these files deploy-time concerns rather than run-time concerns. They will be expressed through a variety of file formats, most commonly in a markup language. Scanning for these assets should most likely be a stand-alone decision for consumers of this capability.
### Requirements
1. Create new vendored template for IaC security scanning https://gitlab.com/gitlab-org/gitlab/-/issues/343820
1. Enable the the category to work within the Configuration UI. ~frontend https://gitlab.com/gitlab-org/gitlab/-/issues/343851 and ~backend https://gitlab.com/gitlab-org/gitlab/-/issues/342864
1. Enable customers to opt-in to IaC SAST scanning separately from programming languages. https://gitlab.com/gitlab-org/gitlab/-/issues/342863
1. Move existing IaC SAST analyzers to new opt-in framework, if necessary.
### Questions
1. How can we reliably discern which IaC tools are being used in a project?
1. Will this capability be realized via 1 analyzer or multiple?
1. Port kubesec and deprecate how it's currently enabled in the SAST vendored template?
- At this time, we're leaning towards not porting kubesec. But, it does make sense to consider deprecating it, based on feature parity with a replacement analyzer.
1. Port the [SASTIaC proof of concept project](https://gitlab.com/greg/sastiac) and extend it to be part of the product we ship?
- Initial work is being realized through a new analyzer.
1. For the Configuration UI, will this be done like Secret Detection, or like SAST?
- IaC will be enabled like Secret Detection. [Issue](https://gitlab.com/gitlab-org/gitlab/-/issues/342864)
1. Will IaC results show alongside existing SAST results (in MR widgets, vulnerability report, etc.), or will it be a completely different category?
- IaC findings will [initially be presented as SAST findings and vulnerabilities](https://gitlab.com/groups/gitlab-org/-/epics/6655#note_699115894) via `gl-sast-report.json` reports.
## Proposal
<!-- Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues. -->
Notes:
* The color change in the screenshot is only to make it easier to differentiate inside this issue
* The analyzer's description should read `Analyze your infrastructure as code configuration files for known vulnerabilities. Learn More`
* ~~The IaC section is right after SAST since it was the easiest to mock up.~~
* ~~The ordering of each of these analyzer section (SAST vs Dependency Scanning vs Container Scanning, etc.) might need to be evaluated. I'm not sure why they're in the order they are in.~~ [Issue for ordering of analyzer sections](https://gitlab.com/gitlab-org/gitlab/-/issues/334929)
* The IaC section should be placed after SAST for the MVC, [since the two scan types are related](https://gitlab.com/groups/gitlab-org/-/epics/6655#note_711834021)
## Decisions
### GraphQL
#### `Mutation.configureIaC` (naming subject to changes)
The ~frontend will need this mutation to be exposed in the GraphQL schema. It will be triggered when clicking on the `Configure via Merge Request` button.
The mutation accepts a `ConfigureIaCInput` argument:
```graphql
ConfigureIaCInput {
projectPath: ID! # The project's full path
}
```
And responds with `ConfigureIaCPayload` payload:
```graphql
ConfigureIaCPayload {
branch: String # Branch where the .gitlab-ci.yml was created/modified
errors: [String!] # Errors that occured while executing the mutation
successPath: String # Redirect URL for when the mutation succeeds (typically, the configure MR's URL)
}
```
## Implementation plan
| Milestone | Issue | Description | Type |
| --------- | ---------------------------------------------------- | ---------------------------------------------------------------------------- | -------------- |
| %"14.5" | https://gitlab.com/gitlab-org/gitlab/-/issues/342864 | Implement the GraphQL mutation's resolver | ~backend |
| %"14.5" | https://gitlab.com/gitlab-org/gitlab/-/issues/343851 | Render the `Configure via Merge Request` in the Security Configuration page | ~frontend |
| %"14.5" | https://gitlab.com/gitlab-org/gitlab/-/issues/343887 | Document how the scanner can be enabled from the Security Configuration page | ~documentation |
<!-- start-discoto-summary -->
## Auto-Summary :robot:
<details>
<summary>Discoto Usage</summary>
---
> **Points**
>
> Discussion points are declared by headings, list items, and single
> lines that start with the text (case-insensitive) `point:`. For
> example, the following are all valid points:
>
> * `#### POINT: This is a point`
> * `* point: This is a point`
> * `+ Point: This is a point`
> * `- pOINT: This is a point`
> * `point: This is a **point**`
>
> Note that any markdown used in the point text will also be propagated
> into the topic summaries.
>
> **Outcomes**
>
> Outcomes define the decisions or resolutions of a discussion. Once
> outcomes are defined, sub-topics and points are collapsed
> underneath the outcomes.
>
> Outcomes are declared in a similar manner as points:
>
> * `#### OUTCOME: This is an outcome`
> * `* outcome: This is an outcome`
> * `+ Outcome: This is an outcome`
> * `- oUTCOME: This is an outcome`
> * `outcome: This is an outcome`
>
> Note that multiple outcomes may be declared for each topic.
>
> **Topics**
>
> Topics can be stand-alone and contained within an issuable (epic,
> issue, MR), or can be inline.
>
> Inline topics are defined by creating a new thread (discussion)
> where the first line of the first comment is a heading that starts
> with (case-insensitive) `topic:`. For example, the following are all
> valid topics:
>
> * `# Topic: Inline discussion topic 1`
> * `## TOPIC: **{+A Green, bolded topic+}**`
> * `### tOpIc: Another topic`
>
> **Quick Actions**
>
> | Action | Description |
> |-------------------------------|---------------------------------------------------------|
> | `/discuss sub-topic TITLE` | Create an issue for a sub-topic. Does not work in epics |
> | `/discuss link ISSUABLE-LINK` | Link an issuable as a child of this discussion |
>
> **Discussion-Size Indicators**
>
> The relative size of the discussion occurring within a topic
> and its sub-topics is indicated via braille dots.
>
> More dots means that more points or sub-topics exist within a
> given topic.
>
> Examples:
>
> * TOPIC `⣿⣿⡆` A large discussion occurred here
> * TOPIC `⣇ ` A smaller discussion occurred here
---
</details>
Last updated by [this job](https://gitlab.com/gitlab-org/secure/pocs/discoto-runner/-/jobs/1721868210)
<ul><li><details><summary>TOPIC <code title='Relative Number of Notes'>⡄ </code> <code title='Relative Number of Actions'> </code> [terraform] How can we reliably discern which IaC tools are being used in a project? https://gitlab.com/groups/gitlab-org/-/epics/6655#note_699223737</summary><ul></ul></details></li><li><details><summary>TOPIC <code title='Relative Number of Notes'>⡆ </code> <code title='Relative Number of Actions'> </code> [cloudformation] How can we reliably discern which IaC tools are being used in a project? https://gitlab.com/groups/gitlab-org/-/epics/6655#note_699229065</summary><ul></ul></details></li><li><details><summary>TOPIC <code title='Relative Number of Notes'>⡀ </code> <code title='Relative Number of Actions'> </code> [ansible] How can we reliably discern which IaC tools are being used in a project? https://gitlab.com/groups/gitlab-org/-/epics/6655#note_699235766</summary><ul></ul></details></li><li><details><summary>TOPIC <code title='Relative Number of Notes'>⡆ </code> <code title='Relative Number of Actions'> </code> Deliver through the SAST vendored template or a brand new one? https://gitlab.com/groups/gitlab-org/-/epics/6655#note_700778301</summary><ul></ul></details></li><li><details><summary>TOPIC <code title='Relative Number of Notes'>⣿⡆</code> <code title='Relative Number of Actions'> </code> Naming https://gitlab.com/groups/gitlab-org/-/epics/6655#note_711834021</summary><ul></ul></details></li></ul>
<!-- end-discoto-summary -->
<!-- start-discoto-topic-settings --><details>
<summary>Discoto Settings</summary>
<br/>
```yaml
---
summary:
max_items: -1
sort_by: created
sort_direction: ascending
```
See the [settings schema](https://gitlab.com/gitlab-org/secure/pocs/discussion-automation#settings-schema) for details.
</details>
<!-- end-discoto-topic-settings -->
epic