Feature/lab6

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,24 @@
+## Goal
+
+<!--What this PR delivers? (1 sentence)-->
+
+## Changes
+
+<!--bullet list of artifacts added/modified-->
+
+-
+
+## Testing
+
+<!--how you verified it works (commands + observed output)-->
+
+```bash
+```
+
+## Artifacts & Screenshots
+
+<!--links to files in this PR, image embeds where useful-->
+
+- [ ] Title is clear (`feat(labN): <topic>` style)
+- [ ] No secrets/large temp files committed
+- [ ] Submission file at `submissions/labN.md` exists

submissions/lab4.md

@@ -0,0 +1,39 @@
+# Lab 4 — Submission
+
+## Task 1: Syft + Grype on Juice Shop
+
+### SBOM stats
+- `juice-shop.cdx.json` component count: 3069
+- `juice-shop.cdx.json` size: 1.8M
+- `juice-shop.spdx.json` component count: 909
+
+### Grype severity breakdown (paste table or JSON)
+| Severity | Count |
+|----------|------:|
+| Critical | 7 |
+| High | 51 |
+| Medium | 35 |
+| Low | 4 |
+| Negligible | 7 |
+| **Total** | 104 |
+
+### Top 10 CVEs (paste from jq output)
+| CVE | Severity | Package | Installed | Fix |
+|-----|----------|---------|-----------|-----|
+| GHSA-c7hr-j4mj-j2w6 | Critical | jsonwebtoken | 0.1.0 | 4.2.2 |
+| GHSA-c7hr-j4mj-j2w6 | Critical | jsonwebtoken | 0.4.0 | 4.2.2 |
+| GHSA-jf85-cpcp-j695 | Critical | lodash | 2.4.2 | 4.17.12 |
+| GHSA-xwcq-pm8m-c4vf | Critical | crypto-js | 3.3.0 | 4.2.0 |
+| CVE-2026-5450 | Critical | libc6 | 2.41-12+deb13u2 | - |
+| CVE-2026-34182 | Critical | libssl3t64 | 3.5.5-1~deb13u2 | 3.5.6-1~deb13u2 |
+| GHSA-5mrr-rgp6-x4gr | Critical | marsdb | 0.6.11 | - |
+| GHSA-35jh-r3h4-6jhm | High | lodash | 2.4.2 | 4.17.21 |
+| GHSA-8hfj-j24r-96c4 | High | moment | 2.0.0 | 2.29.2 |
+| GHSA-p6mc-m468-83gw | High | lodash.set | 4.3.2 | - |
+
+### Fix-available rate
+Out of the top 10 CVEs, how many have a fix available? What does that say about your
+patch cadence priorities? (2-3 sentences. Reference Lecture 4's triage shortcut:
+*sort by fix-available AND severity ≥ HIGH first*.)
+
+7 out of 10 have a fix available. Priority should be given to fixing those vulnerabilities that are patchable and have a high or critical severity level. For all other vulnerabilities without a fix, the only option is to wait for an image update. 

submissions/lab5.md

@@ -0,0 +1,67 @@
+# Lab 5 — Submission
+
+## Task 1: DAST with OWASP ZAP
+
+### Baseline (unauthenticated) scan
+- Duration: 1m 14 s
+- Total alerts: 10 \
+| Severity | Count | \
+|----------|------:|\
+| High | 0 |\
+| Medium | 2 |\
+| Low | 5 |\
+| Informational | 3 |
+
+### Authenticated full scan
+- Duration: 15m 34 s
+- Total alerts: 12\
+| Severity | Count |\
+|----------|------:|\
+| High | 1 |\
+| Medium | 4 |\
+| Low | 3 |\
+| Informational | 4 |
+
+### The "10–20× more" claim (Lecture 5 slide 11)
+- Ratio (auth alerts / baseline alerts): 1.2×
+- Did your run match the lecture's ratio? (2-3 sentences)\
+
+No, my ratio is much lower because, in Juice Shop, all the vulnerabilities are intentionally exposed; consequently, both authenticated and unauthenticated scans find roughly the same number of vulnerabilities. In standard applications, however, most vulnerabilities are hidden behind a login, so unauthenticated scans detect far fewer vulnerabilities than authenticated ones—hence the high ratio.
+- Pick **two specific alerts** that only the authenticated scan found. For each:
+  1. SQL injection - high severity
+  2. Why was it unreachable to the unauthenticated scan? (1 sentence)\
+  An unauthenticated scan did not detect this vulnerability, as access to database query results requires authorization.
+
+## Task 2: SAST with Semgrep
+
+### Semgrep severity breakdown
+| Severity | Count |
+|----------|------:|
+| ERROR | 12 |
+| WARNING | 10 |
+| INFO | 0 |
+| **Total** | 22 |
+
+### Top 10 rules by frequency
+| Rule ID | Count | OWASP category |
+|---------|------:|----------------|
+| javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection | 6 | A03 Injection |
+| yaml.github-actions.security.run-shell-injection.run-shell-injection | 5 | A03 Injection |
+| javascript.express.security.audit.express-check-directory-listing.express-check-directory-listing | 4 | A05 Security Misconfiguration |
+| javascript.express.security.audit.express-res-sendfile.express-res-sendfile | 4 | A01 Broken Access Control |
+| javascript.express.security.audit.express-open-redirect.express-open-redirect | 1 | A01 Broken Access Control |
+| javascript.jsonwebtoken.security.jwt-hardcode.hardcoded-jwt-secret | 1 | A07 Identification Failures |
+| javascript.lang.security.audit.code-string-concat.code-string-concat | 1 | A03 Injection |
+
+### Triage shortcut (Lecture 5 slide 8)
+Looking at the top 10 — which **one rule** would you fix first if you had time for only one?
+Why? (2-3 sentences. Likely answer: the highest-frequency rule that's not a duplicate
+of patterns the team already knows about; one fix at the module level closes many findings.)
+
+``javascript.sequelize.security.audit.sequelize-injection-express.express-sequelize-injection``. This category accounts for the highest number of vulnerabilities-specifically instances where developers used raw SQL code within Sequelize with direct user input substitution, making it easy for an attacker to inject SQL injections. However, since all six vulnerabilities stem from the same database module, a single fix resolves them all.
+
+### False-positive sample
+Pick **one** finding you'd suppress as a false positive after review. Quote the file path +
+rule + 1-sentence reason. (NOT generic — must reference the specific code.)
+
+labs/lab5/semgrep/lib/botUtils.ts - javascript.express.security.audit.express-check-directory-listing - The trigger occurred in a bot utility that checks for the existence of files based on a predefined list of paths rather than user input; there is no risk of directory traversal.

submissions/lab6.md

@@ -0,0 +1,73 @@
+# Lab 6 — Submission
+
+## Task 1: Checkov on Terraform + Pulumi
+
+### Terraform scan
+- Total checks: 127
+- Passed: 49
+- Failed: 78
+
+| Severity | Count |
+|----------|------:|
+| Critical | 2 |
+| High | 35 |
+| Medium | 28 |
+| Low | 13 |
+
+### Top 5 rule IDs (by frequency)
+| Rule | Count | What it checks |
+|------|------:|----------------|
+| Ensure no IAM policies documents allow "*" as a statement's resource for restrictable actions | 4 | IAM policies must not use wildcard resources |
+| Ensure IAM policies does not allow permissions management / resource exposure without constraints | 4 | IAM policies must restrict permission management actions |
+| Ensure no security groups allow egress from 0.0.0.0:0 to port -1 | 3 | Security groups must not allow unrestricted outbound traffic |
+| Ensure IAM policies does not allow write access without constraints | 3 | IAM policies must restrict write actions |
+| Ensure IAM policies does not allow data exfiltration | 3 | IAM policies must prevent data exfiltration via wildcard actions |
+
+### Pulumi scan
+| Severity | Count |
+|----------|------:|
+| CRITICAL | 1 |
+| HIGH | 2 |
+| MEDIUM | 1 |
+| LOW | 0 |
+| INFO | 2 |
+| **Total** | 6 |
+
+### Module-leverage analysis (Lecture 6 slide 17)
+Looking at your top-5 Terraform rules, which ONE fix would eliminate the most findings if applied
+at the module level? (2-3 sentences. e.g., "If the S3 module had `block_public_acls = true` as default,
+the 8 findings of CKV_AWS_56 would all go away.")
+
+The most efficient fix is ​​to create a unified IAM module where wildcard permissions **action** and **resource** are denied by default. Currently, these two issues result in eight findings. Instead of fixing each file manually, you simply need to define the restrictions in the module once - this resolves all eight vulnerabilities and prevents new ones from appearing.
+
+## Task 2: KICS on Ansible
+
+### Severity breakdown
+| Severity | Count |
+|----------|------:|
+| HIGH | 9 |
+| MEDIUM | 0 |
+| LOW | 1 |
+| INFO | 0 |
+| **Total** | 10 |
+
+### Top 5 KICS queries (by frequency)
+| Query | Severity | Files |
+|-------|---------|------:|
+| Generic Password | HIGH | 7 |
+| Password in URL | HIGH | 2 |
+| Generic Secret | HIGH | 1 |
+| DynamoDB Not Encrypted | HIGH | 1 |
+| RDS Publicly Accessible | CRITICAL | 1 |
+
+### Checkov vs KICS — when to use which? (Lecture 6 slide 10)
+2-3 sentences each:
+- One thing Checkov did **better** for the Terraform sample
+
+**Checkov** found 78 issues in the Terraform code because it is specifically tailored for Terraform. It employs specialized graph-based rules that verify the relationships between resources - something **KICS** doesn't delve into as deeply when it comes to Terraform.
+- One thing KICS did **better** for the Ansible sample
+
+**KICS** can read Ansible out of the box. **Checkov** cannot scan Ansible at all; it would simply skip that folder.
+- (Optional) An example of a finding only ONE of them caught for the same resource type
+
+**RDS Publicly Accessible** - **KICS** detected an internet-exposed RDS database in the Pulumi file - meaning anyone could attempt to connect to it. **Checkov** would have missed this vulnerability because it cannot read Pulumi files directly and requires specially generated JSON, whereas **KICS** reads the file directly.