lab 5 fixes

## Overview

Security vulnerabilities are inevitable. The earlier they are caught, the cheaper and faster they are to fix. In this lab, four DAP capabilities come together on a single real problem, and the problem was found by something you built.

Security vulnerabilities are inevitable. The earlier they are caught, the cheaper and faster they are to fix. In this lab, four DAP capabilities come together on a single real problem.

A few weeks in, the Issue Reviewer flags an issue scored 2 out of 6. The title says "possible security problem in search." You click through to the vulnerability report to see what the author was referring to. It's a SQL injection vulnerability in app.py at line 214, sitting in the report long enough to become invisible. Not dismissed, not resolved, just present.

In this lab, you will learn about the vulnerability using AI, generate a fix, resolve a dependency problem that breaks the pipeline along the way, get a security-aware code review, and merge.

The Swag Shop project has a SQL injection vulnerability in app.py that has been sitting in the vulnerability report unresolved. You generate a fix, but while the merge request is open you also need to update a dependency. A typo in the package name breaks the pipeline. You use the Fix Pipeline flow to diagnose and resolve it, then get an AI code review on the security fix and merge.

## Task A: Locate the Vulnerability

## Task B: Understand and Remediate the Vulnerability

You now have one open vulnerability to work with. In this task, you will ask GitLab Duo to explain it in plain language, then generate a merge request that fixes it. By the end of Task B, you will have one open merge request (the remediation merge request) on its own branch.

You now have one open vulnerability to work with. In this task, you will ask GitLab Duo to explain it in plain language, then generate a merge request that fixes it. By the end of Task B, you will have one open merge request — the remediation merge request — on its own branch.

### Task B.1: Explain the Vulnerability

Now that you understand the vulnerability, use DAP to generate a fix.

1. Select **AI vulnerability management** again, then select **Resolve with AI**.

1. Select **AI vulnerability management** again, and then select **Resolve with AI**.

1. Wait for the session to complete. When it finishes, a merge request will open automatically.

   cursor.execute(secure_query, (search_param, search_param))

   ```

1. Select the **Pipelines** tab and wait for the pipeline to complete.

>**Note:** You may see new vulnerabilities flagged in the pipeline security results. These are pre-existing findings in the codebase surfaced by the scan, not issues introduced by the remediation. They do not affect the pipeline status.

1. Select the **Pipelines** tab. You may notice the pipeline status shows as skipped. This is expected. The commit created by Resolve with AI includes **[ci skip]** by default. A real pipeline will run after the next commit to this branch, which you will make in Task C.

### Expected output: Task B

- An agentic chat session explains the SQL injection vulnerability in plain language.

- One merge request — the remediation merge request — is visible under **Code > Merge Requests**, with changes to app.py that address the vulnerability.

- The pipeline on the remediation merge request is passing.

## Task C: Break and Fix the Pipeline

## Task C: Fix the Pipeline

At this point you have one open merge request, the remediation merge request, with a passing pipeline on its branch. In this task, you will deliberately introduce a dependency error onto that branch, watch the pipeline fail, and use the Fix Pipeline flow to resolve it.

With the remediation merge request open, you need to update a project dependency. You add the package to `requirements.txt` but make a typo in the package name. The pipeline runs and fails. Before you can merge the vulnerability fix, you need to resolve this first.

This simulates something that happens constantly in real development: a developer makes a code fix, updates a dependency file at the same time, makes a small mistake in the dependency name, and commits without realizing the build will break. The Fix Pipeline flow is designed exactly for this moment.

### Task C.1: Introduce the Dependency Error

### Task C.1: Introduce a Deliberate Pipeline Failure

1. Navigate to **Code > Merge Requests** and open the remediation merge request.

1. Note the source branch name shown in the merge request header. You will need this to navigate to the correct branch.

1. Note the source branch name shown in the remediation merge request header. It will be like `remediate/improper-neutral...`. You will need this in the next step.

1. In the left sidebar, navigate to **Code > Repository**.

1. Click the branch dropdown at the top of the file list and select the remediation branch name. The file list now shows the contents of the remediation branch.

1. Click the branch dropdown and change the branch from `main` to your remediation branch. The file list now shows the contents of the remediation branch.

1. Open `requirements.txt` from the file list.

1. Click **Edit > Open in Web IDE** to open the file in the web editor.

1. Click **Edit > Open in Web IDE**.

1. Add the following line anywhere in the file: `nonexistent-package==1.0.0`.

1. Add the following line anywhere in the file: `nonexistent-package==1.0.0`

1. In the left toolbar, select the **Source Control** icon to see your pending changes.

1. In the **Commit message** field, enter: `updated requirements`.

1. Ensure you are committing to the remediatation branch, and then commit the changes.

   >**Note:** You do not need to create a new merge request. Committing to the remediation branch automatically updates the existing remediation merge request. The pipeline failure will appear there.

1. Navigate back to the remediation merge request and open the **Pipelines** tab.

1. Commit the changes to the remediation branch. 

1. Wait for the pipeline to run and confirm it fails. You should see a failed status on the pipeline and a red indicator on the MR.

You do not need to create a new merge request. Committing to the remediation branch automatically updates the existing remediation merge request and triggers a new pipeline run.

### Task C.2: Read the Failure and Trigger the Fix Pipeline Flow

### Task C.2: Read the Failure

Before triggering the fix, read the error so you understand what the Fix Pipeline flow is about to solve.

1. Click the failed pipeline to open its detail view.

1. From the remediation merge request, select the **Pipelines** tab. Wait for the pipeline to complete and confirm it shows a failed status.

1. Locate the failed job and click it to open its log. Review the error. 

1. Click the failed pipeline to open its detail view.

1. Confirm you see output similar to similar to:

1. Locate the failed job and click it to open its log. Confirm you see output similar to:

   ```yaml

   ERROR: Could not find a version that satisfies the requirement nonexistent-package==1.0.0

   >**Note:** You do not need to fix this manually. Reading the log confirms what failed and helps you understand what the Fix Pipeline flow will do next.

1. Navigate back to the failed pipeline overview page by selecting the pipeline ID in the breadcrumb at the top of the page, for example, #12345.

1. At the top of the page, look for the **Fix pipeline with Duo** button and click it.

### Task C.3: Trigger the Fix Pipeline Flow

### Task C.3: Observe the Fix Pipeline Flow

1. Navigate to **Build > Pipelines** and select the pipeline ID, like #12345, of your `updated requirements` pipeline.

1. Navigate to **Automate > Sessions** in the left sidebar.

1. At the top of the page, click **Fix pipeline with Duo**.

1. Locate the session for the Fix Pipeline flow and open it.

   >**Note:** The session should open automatically. If it does not, navigate to **Automate > Sessions** and locate the session for the Fix Pipeline flow.

1. Click the **Activity** tab and observe the steps the flow is executing: log analysis, root cause identification, and file modification.

1. Wait for the session status to change to **Finished** before proceeding.

1. Wait for the session status to change to **Finished** on the **Details** tab before proceeding.

>**What the flow is doing:** The Fix Pipeline flow reads the failed job log, identifies the root cause (a package that does not exist), locates the file responsible (requirements.txt), and opens a new merge request with the bad entry removed. Notice that the flow creates a merge request rather than committing directly to the branch. This is intentional: DAP follows the same review process you would expect from any developer on the team. The fix is proposed, not imposed.

>**What the flow is doing:** The Fix Pipeline flow reads the failed job log, identifies the root cause (a package that does not exist), locates the file responsible (requirements.txt), and opens a new merge request with the bad entry removed. Notice that the flow creates a merge request rather than committing directly to the branch. This is intentional: DAP follows the same review process you would expect from any developer on the team.

### Task C.4: Review and Merge the Fix Merge Request

When the session finishes, you will have two open merge requests: the original remediation MR and a new fix merge request created by the Fix Pipeline flow. In this step, you are working with the fix merge request only.

The Fix Pipeline flow has created a new merge request, the fix merge request, that targets the remediation branch. You are working in the fix merge request for the rest of this task.

1. Follow the link in the session output to the fix merge request. If you don't see the link, navigate to **Code > Merge Requests** and look for the merge request created by the Fix Pipeline flow. It will have a title referencing the `requirements.txt fix`.

1. Follow the link in the session output to the fix merge request. If you don't see the link, navigate to **Code > Merge Requests** and look for the merge request created by the Fix Pipeline flow.

1. On the **Changes** tab, confirm that `nonexistent-package==1.0.0` has been removed from `requirements.txt` and that no other changes have been made.

1. Select the **Overview** tab.

1. Select **Mark as ready**, and then select **Merge** to merge the fix into the remediation branch.

1. Select the **Pipelines** tab and wait for the pipeline to complete successfully.

### Task C.5: Confirm the Remediation Merge Request Pipeline Passes

1. Navigate back to the merge request and select the **Overview** tab.

Merging the fix MR into the remediation branch triggered a new pipeline automatically. Do not proceed to Task D until that pipeline passes.

1. Select **Mark as ready** to convert the merge request from a draft, and then select **Merge**. This merges the fix into the remediation branch, not the main branch.

1. Navigate to **Code > Merge Requests** and open the remediation merge request.

1. Select the **Pipelines** tab. It could take a minute or two for the new pipeline to appear.

1. Wait for the pipeline to complete and confirm the status is green.

1. To confirm the fix, navigate to **Code > Repository** and open `requirements.txt`. Confirm that `nonexistent-package==1.0.0` has been removed.

### Expected output: Task C

- The Fix Pipeline flow session is visible under **Automate > Sessions** with a status of **Finished**.

- The flow opened a merge request removing `nonexistent-package==1.0.0 from requirements.txt`.

- That fix merge request has been merged into the remediation branch.

- The fix merge request has been merged into the remediation branch.

- The pipeline on the remediation merge request is now passing.

## Task D: Trigger the Code Review Flow

At this point you have one open merge request, the remediation merge request, with a passing pipeline. Before merging, you will run the Code Review Flow to get AI feedback on the fix.

### Task D.1 Mark the Merge Request as Ready

The Code Review Flow only runs on merge requests that are out of draft status. Draft merge requests are excluded from review workflows.

1. Navigate to **Code > Merge Requests** and open the remediation merge request.

1. Select the **Overview** tab.

1. Scroll down and click **Mark as ready**.

### Task D.2: Assign GitLab Duo as a Reviewer

1. On the merge request overview page, locate the **Reviewers** section in the right sidebar. 

1. On the **Overview** page, locate the **Reviewers** section in the right sidebar. 

1. Click **Edit** and search for GitLabDuo. Select it to assign GitLab Duo as a reviewer.

   >**Alternative trigger:** You can also type `/assign_reviewer @GitLabDuo` in any comment box on the merge request.

### Task D.3: Observe the Flow and Review Output

1. Navigate to **Automate > Sessions** and locate the new Code Review Flow session.

1. Click the **Activity** tab and observe the steps in real time. The flow runs in three steps: building review context, reasoning over what it found, and generating recommendations. Notice how many files it reads beyond just the changed file. That cross-file context is what gives the review its depth.

1. Wait for the session status to change to **Finished**.

1. Return to the merge request **Overview** tab and review the comments posted by GitLab Duo.

1. On the merge request **Overview** tab, scroll down to the activity feed to observe the Code Review Flow running in real time.

> **What to look for in the review:** Because this merge request addresses a SAST vulnerability, the Code Review Flow has additional context beyond just the code diff. It can see the linked vulnerability finding, the original SQL injection pattern, and the parameterized query replacement. Its feedback should reflect the security nature of the change, not just style or structure. Compare this to the review you saw in Lab 1, which was focused on a feature addition. Same flow, same trigger mechanism, which gives a different depth of feedback because of the different context.

1. Wait for GitLab Duo to finish its review, then read the comments it has posted on the merge request.

### Expected output: Task D

- GitLab Duo is assigned as a reviewer on the remediation MR.

- A Code Review Flow session is visible under **Automate > Sessions** with a status of **Finished**.

- One or more review comments are posted by GitLab Duo, with at least one referencing the SQL injection vulnerability or the parameterized query fix.

- One or more review comments are posted by GitLab Duo.

## Task E: Merge the Fix and Confirm Resolution

1. Select the **Overview** tab.

1. Scroll down and review the **Fix Provided** field. This field is generated by DAP and summarizes the specific code changes made to address the vulnerability, confirming what was fixed and why. If this field is not visible, proceed to merge. Its presence depends on how the remediation merge request was generated.

1. Review the **AI Generated Fix** field. This summarizes the specific code changes made to address the vulnerability, confirming what was fixed and why. 

1. Select **Merge**.

1. Scroll down, and select **Merge**.

1. Select the pipeline number to observe when the merge pipeline completes.