Confirming My Test Repository Setup

1. First, I made sure that I had forked the Juice Shop repository into an organization where GitHub Advanced Security (GHAS) was enabled. This was a crucial step.

2. I then went to my repository on GitHub and clicked on the "Actions" tab under the repository name. For those who can't find it immediately, it's sometimes hidden in the “...” dropdown menu.

Activating GitHub Advanced Security

3. Next, on my Juice Shop repository's GitHub page, I clicked "Settings" right under the repository name. Like with the Actions tab, if it's not visible immediately, it's in the “...” dropdown.

4. In the sidebar, under "Security," I found and clicked on "Code security and analysis."

5. Scrolling down, I reached the "GitHub Advanced Security" section and clicked "Enable." In cases where it says "Disable," it means GHAS is already enabled, which is helpful to know.

Enabling Secret Scanning

6. In the same "Code security and analysis" section, I located "Secret scanning" and clicked "Enable" next to it. If this option says "Disable," it indicates that secret scanning is already active.

7. After enabling secret scanning, a new feature called "Push protection" appeared under "Secret scanning." I made sure to enable this as well for added security.
   
   Setting Up CodeQL

8. Before I could enable CodeQL, it was essential to activate GitHub Actions, especially since my repository was a fork. On the GitHub.com page for my Juice Shop repository, I clicked "Actions" under the repository name. If it wasn't directly visible, I found it in the “...” dropdown menu. There, I clicked on "I understand my workflows, go ahead and enable them."

9. Next, I returned to the "Settings" under my repository name, accessible in the “...” dropdown menu if it's not immediately visible.

10. In the "Security" section of the sidebar, I chose "Code security and analysis."

11. In the "Code scanning" area, I selected "Set up." This led me to two options: Default and Advanced. I opted for the Default setting for now.

12. A dialog appeared, titled "CodeQL default configuration." This dialog summarized the automatically generated configuration, including the selected languages and queries. I decided to keep these default settings, recognizing that the default query suite is optimized to effectively secure the code with minimal false positives.

13. Finally, I clicked "Enable CodeQL."

14. With CodeQL enabled, I'm now prepared to delve deeper into static analysis on my repository, a crucial step for maintaining code quality and security.

15. The upcoming steps will involve enabling and configuring other supply chain security features.

Adding an Invalid Secret to the Repository

16. - I navigated to the `README.md` file in my Juice Shop repository.

17. - Into the document, I inserted the following invalidated secret: `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`. This was a safe practice since the secret had already been rendered inactive.

18. - Upon committing the changes, a "Secret Detected" notification popped up, alerting me to the presence of a GitHub Personal Access Token. It offered options like "It's used in tests," "It's a false positive," or "I'll fix it later" to handle the secret appropriately.

19. - I chose "I'll fix this later" and then "Allow Secret," before finalizing the commit.

Viewing Dependabot Alerts

20. - On the GitHub.com page of my Juice Shop repository, under "Settings," I accessed the "Security" tab.

21. - I clicked on the "Dependabot" option in the sidebar to view the security alerts.

22. - The Dependabot page showed a prioritized list of alerts, which I could filter by package, ecosystem, manifest, or severity.

23. - I focused on the "Verification Bypass in jsonwebtoken" alert and clicked the "Review security update" button to automatically create a pull request for resolving the vulnerability.

Viewing Code Scanning Results

24. - Under the "Security" tab of my repository, I selected "Code scanning" from the sidebar.

25. - This page provided a list of vulnerabilities, organized by their severity, with options to filter and sort them.

26. - By selecting a "Code injection" alert, I was directed to a detailed page designed for remediation, including language-specific code examples and a "Show paths" link to trace the vulnerability.

Viewing Secret Scanning Results

27. - Continuing in the "Security" section, I clicked on "Secret scanning."

28. - This section highlighted an alert related to the GitHub Personal Access Token I had previously added. The page offered detailed information about the secret’s location and suggestions for remediation.

29. - By examining the secret, I could view the history of actions taken, including my earlier decision to bypass the alert.

Viewing the Security Overview

30. - I visited the "Security" tab on my organization page on GitHub.com.

31. - This overview allowed me to see alerts from Dependabot, code scanning, and secret scanning across all repositories in my organization, with options to filter these alerts by risk level or source.

32. - It also provided insights into which repositories were under the protection of GitHub Advanced Security, along with metrics like mean time to remediation (MTTR) and the number of secrets that had been blocked or bypassed.

33. Through these steps, I have deepened my understanding of managing and interacting with GitHub Advanced Security, enhancing my capability to maintain high security standards in my coding projects.