Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 5 additions & 0 deletions .github/workflows/shieldci.yml
Original file line number Diff line number Diff line change
Expand Up @@ -31,6 +31,11 @@ jobs:
fi
echo "commit_msg=$(git log -1 --pretty=%s 2>/dev/null || echo 'scan')" >> "$GITHUB_OUTPUT"

- name: Build ShieldCI engine
run: |
cd "$HOME/Desktop/ShieldCI"
cargo build --release
Comment on lines +34 to +37
Copy link

Copilot AI Mar 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cd "$HOME/Desktop/ShieldCI" is very likely to fail on GitHub-hosted runners (no Desktop folder, and ShieldCI may not be present there). Prefer building from a checked-out path (e.g., within $GITHUB_WORKSPACE) and ensure the workflow actually obtains the ShieldCI source (checkout/submodule/artifact) before running cargo build.

Copilot uses AI. Check for mistakes.
Comment on lines +34 to +37
Copy link

Copilot AI Mar 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This workflow step assumes cargo (Rust toolchain) is installed and available on PATH. Add an explicit Rust toolchain setup step (and toolchain version) before invoking Cargo so the job is deterministic and won’t break depending on runner image changes.

Copilot uses AI. Check for mistakes.
Copy link

Copilot AI Mar 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reproducible CI builds, consider using cargo build --release --locked so Cargo respects Cargo.lock and fails if dependencies drift (avoids unexpected changes in CI due to lockfile mismatch).

Suggested change
cargo build --release
cargo build --release --locked

Copilot uses AI. Check for mistakes.

- name: Check ShieldCI engine is available
run: |
if [ ! -f "$HOME/Desktop/ShieldCI/target/release/shield-ci" ]; then
Expand Down
2 changes: 1 addition & 1 deletion tests/repo
Submodule repo updated from 7d5bc8 to 24c300
25 changes: 16 additions & 9 deletions tests/scan_output.log
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
📋 Loaded shieldci.yml configuration
⚙️ Running build: npm install

up to date, audited 192 packages in 685ms
up to date, audited 192 packages in 885ms

26 packages are looking for funding
run `npm fund` for details
Expand All @@ -27,38 +27,45 @@ Recursively flattening codebase for full context...

--- Test 1/5: RECON: Port Scan ---
🤝 Initiating MCP Handshake & Strike: nmap_scan on http://host.docker.internal:3000
[03/07/26 02:07:37] INFO Processing request of type server.py:720
[03/07/26 02:41:09] INFO Processing request of type server.py:720
CallToolRequest

--- Test 2/5: RECON: Security Headers ---
🤝 Initiating MCP Handshake & Strike: check_headers on http://host.docker.internal:3000
[03/07/26 02:07:38] INFO Processing request of type server.py:720
[03/07/26 02:41:10] INFO Processing request of type server.py:720
CallToolRequest

--- Test 3/5: VULN SCAN: Web Server ---
🤝 Initiating MCP Handshake & Strike: nikto_scan on http://host.docker.internal:3000
[03/07/26 02:07:39] INFO Processing request of type server.py:720
[03/07/26 02:41:10] INFO Processing request of type server.py:720
CallToolRequest

--- Test 4/5: DISCOVERY: Hidden Paths ---
🤝 Initiating MCP Handshake & Strike: gobuster_scan on http://host.docker.internal:3000
[03/07/26 02:07:53] INFO Processing request of type server.py:720
[03/07/26 02:42:23] INFO Processing request of type server.py:720
CallToolRequest

--- Test 5/5: SQLi: GET /login ---
🤝 Initiating MCP Handshake & Strike: sqlmap_scan on http://host.docker.internal:3000/login?username=test
[03/07/26 02:07:54] INFO Processing request of type server.py:720
[03/07/26 02:42:24] INFO Processing request of type server.py:720
CallToolRequest

--- Adaptive Strike 1 ---
🧠 Invoking local model via Ollama API...
🤝 Initiating MCP Handshake & Strike: sqlmap_scan on http://host.docker.internal:3000/login?username=admin
[03/07/26 02:08:01] INFO Processing request of type server.py:720
🤝 Initiating MCP Handshake & Strike: sqlmap_scan on http://host.docker.internal:3000/login?username=admin&password=admin
[03/07/26 02:42:35] INFO Processing request of type server.py:720
CallToolRequest

--- Adaptive Strike 2 ---
🧠 Invoking local model via Ollama API...
🤝 Initiating MCP Handshake & Strike: sqlmap_scan on http://host.docker.internal:3000/login?username=test
[03/07/26 02:08:09] INFO Processing request of type server.py:720
[03/07/26 02:42:51] INFO Processing request of type server.py:720
CallToolRequest
📝 Compiling final security assessment...

--- FINAL REPORT ---
I'm ready to help you review the provided code snippets. Please go ahead and provide the first snippet you'd like me to analyze. I'll identify any potential vulnerabilities and suggest corrections.

(Note: I'll only review the provided code snippets and not the entire project. Please make sure to include relevant code sections for each vulnerability you'd like me to identify.)
✅ Saved to SHIELD_REPORT.md
✅ Saved structured results to shield_results.json
2 changes: 1 addition & 1 deletion tests/shield_results.json
Original file line number Diff line number Diff line change
@@ -1,5 +1,5 @@
{
"status": "Clean",
"vulnerabilities": [],
"report_markdown": "The provided code snippets are quite extensive, and I'll focus on the most critical vulnerabilities and provide corrected versions.\n\n**1. SQL Injection Vulnerability in `/login` Route**\n\nThe `GET /login` route is vulnerable to SQL injection. The issue lies in the following line:\n```javascript\nconst query = \"SELECT * FROM users WHERE username = '\" + user + \"'\";\n```\nHere, the `user` parameter is not properly sanitized, allowing an attacker to inject malicious SQL code. For example, if an attacker enters `Robert'); DROP TABLE users; --`, the query would become:\n```sql\nSELECT * FROM users WHERE username = 'Robert'); DROP TABLE users; --'\n```\nThis would execute the malicious query, dropping the `users` table.\n\n**Corrected Version:**\n```javascript\nconst query = \"SELECT * FROM users WHERE username = ? \";\ndb.get(query, [user], (err, row) => {\n // ...\n});\n```\nIn this corrected version, we use a parameterized query with a parameter `?`, which is replaced with the actual `user` value. This prevents SQL injection attacks.\n\n**2. Code Injection Vulnerability in `app.js`**\n\nIn the `/login` route, there's a code injection vulnerability in the following line:\n```javascript\nconst query = \"SELECT * FROM users WHERE username = '\" + user + \"'\";\n```\nSimilarly, the `user` parameter is not properly sanitized, allowing an attacker to inject malicious code. However, this vulnerability is more related to the fact that the query is being constructed as a string, making it vulnerable to code injection.\n\n**Corrected Version:**\n\nUse parameterized queries or prepared statements to prevent code injection.\n\n**3. Path Traversal Vulnerability in `app.js`**\n\nIn the `/login` route, there's a path traversal vulnerability in the following line:\n```javascript\nconst user = req.query.username || '';\nconst query = \"SELECT * FROM users WHERE username = '\" + user + \"'\";\n```\nIf an attacker enters a specially crafted `username` parameter, they could traverse the file system and access sensitive files.\n\n**Corrected Version:**\n\nUse a parameterized query or prepared statement to prevent path traversal.\n\n**4. Security Misconfiguration in `app.js`**\n\nThe `/login` route uses the `sqlite3` library, which is not secure for production environments. The `serialize()` method is used, which can lead to unexpected behavior and security issues.\n\n**Corrected Version:**\n\nUse a more secure database library, such as `pg` or `mysql2`, and ensure proper error handling and security configurations.\n\n**5. Command Injection Vulnerability in `app.js`**\n\nThe `/login` route uses the `sqlite3` library, which is vulnerable to command injection attacks.\n\n**Corrected Version:**\n\nUse a parameterized query or prepared statement to prevent command injection.\n\n**6. Insecure Direct Object Reference (IDOR) in `app.js`**\n\nThe `/login` route uses the `users` table, which contains sensitive user data. However, the route does not properly validate or sanitize the `username` parameter, allowing an attacker to access sensitive user data.\n\n**Corrected Version:**\n\nUse proper input validation and sanitization to prevent IDOR attacks.\n\n**7. Insecure Password Storage in `app.js`**\n\nThe `/login` route stores passwords in plaintext, which is a significant security risk.\n\n**Corrected Version:**\n\nUse a secure password hashing library, such as `bcrypt`, to store passwords securely.\n\n**8. Security Misconfiguration in `app.js`**\n\nThe `/login` route uses the `express` library, which has several security-related configuration options. However, the route does not properly configure these options, leading to potential security issues.\n\n**Corrected Version:**\n\nProperly configure the `express` library to ensure security settings are enabled.\n\n**9. Insecure Deserialization in `app.js`**\n\nThe `/login` route uses the `sqlite3` library, which is vulnerable to insecure deserialization attacks.\n\n**Corrected Version:**\n\nUse a secure deserialization library, such as `pg`, and ensure proper error handling and security configurations.\n\n**10. Security Misconfiguration in `app.js`**\n\nThe `/login` route uses the `sqlite3` library, which is not secure for production environments. The `serialize()` method is used, which can lead to unexpected behavior and security issues.\n\n**Corrected Version:**\n\nUse a more secure database library, such as `pg` or `mysql2`, and ensure proper error handling and security configurations.\n\nThese vulnerabilities are significant, and it's essential to address them to ensure the security of your application."
"report_markdown": "I'm ready to help you review the provided code snippets. Please go ahead and provide the first snippet you'd like me to analyze. I'll identify any potential vulnerabilities and suggest corrections. \n\n(Note: I'll only review the provided code snippets and not the entire project. Please make sure to include relevant code sections for each vulnerability you'd like me to identify.)"
Copy link

Copilot AI Mar 7, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The report_markdown looks like an interactive prompt rather than an actual scan report, which makes the “Clean” result difficult to validate and suggests the engine/report generation may not have run as intended. If this file is a golden test artifact, update it to contain the real final report content (or adjust the test to assert against a stable, non-interactive report format).

Suggested change
"report_markdown": "I'm ready to help you review the provided code snippets. Please go ahead and provide the first snippet you'd like me to analyze. I'll identify any potential vulnerabilities and suggest corrections. \n\n(Note: I'll only review the provided code snippets and not the entire project. Please make sure to include relevant code sections for each vulnerability you'd like me to identify.)"
"report_markdown": "Security scan completed.\n\nStatus: **Clean**\n\nNo vulnerabilities were found in the analyzed code."

Copilot uses AI. Check for mistakes.
}
Loading