@intentsolutionsio/security-pro-pack 1.0.0 → 1.0.8
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -2
- package/package.json +1 -1
- package/skills/performing-security-audits/SKILL.md +17 -5
- package/skills/performing-security-audits/assets/compliance_report_template.md +13 -13
- package/skills/performing-security-audits/assets/security_scan_report_template.md +43 -43
- package/skills/performing-security-audits/assets/threat_model_template.md +46 -46
- package/skills/performing-security-audits/references/README.md +0 -1
- package/skills/performing-security-audits/scripts/{security_scan.sh → security_scan.py} +15 -13
package/README.md
CHANGED
|
@@ -11,6 +11,7 @@ Version 1.0.0 | 10 Plugins | Security & Compliance Focus
|
|
|
11
11
|
The **Security Pro Pack** is a comprehensive collection of security-focused plugins for Claude Code, providing automated vulnerability scanning, compliance checking, cryptography review, and infrastructure security analysis.
|
|
12
12
|
|
|
13
13
|
**Perfect for:**
|
|
14
|
+
|
|
14
15
|
- Security engineers and DevSecOps teams
|
|
15
16
|
- Developers building secure applications
|
|
16
17
|
- Companies preparing for compliance audits (HIPAA, PCI DSS, GDPR, SOC 2)
|
|
@@ -136,24 +137,28 @@ claude plugin install security-pro-pack
|
|
|
136
137
|
## Who Should Use This
|
|
137
138
|
|
|
138
139
|
### Security Engineers
|
|
140
|
+
|
|
139
141
|
- Automate security reviews
|
|
140
142
|
- Scale security across teams
|
|
141
143
|
- Implement security gates in CI/CD
|
|
142
144
|
- Perform threat modeling efficiently
|
|
143
145
|
|
|
144
146
|
### Development Teams
|
|
147
|
+
|
|
145
148
|
- Shift security left (find issues early)
|
|
146
149
|
- Learn security best practices
|
|
147
150
|
- Meet compliance requirements
|
|
148
151
|
- Ship secure code faster
|
|
149
152
|
|
|
150
153
|
### Compliance Officers
|
|
154
|
+
|
|
151
155
|
- Generate audit-ready documentation
|
|
152
156
|
- Track compliance gaps
|
|
153
157
|
- Prepare for regulatory audits
|
|
154
158
|
- Maintain compliance posture
|
|
155
159
|
|
|
156
160
|
### DevOps Teams
|
|
161
|
+
|
|
157
162
|
- Secure container deployments
|
|
158
163
|
- Harden Kubernetes configurations
|
|
159
164
|
- Automate security scanning in pipelines
|
|
@@ -184,7 +189,7 @@ claude plugin install security-pro-pack
|
|
|
184
189
|
|
|
185
190
|
- **Email:** [email protected]
|
|
186
191
|
- **GitHub Issues:** https://github.com/jeremylongshore/claude-code-plugins/issues
|
|
187
|
-
- **Documentation:**
|
|
192
|
+
- **Documentation:** security-pro-pack
|
|
188
193
|
- **Discord:** https://discord.gg/claude-code-plugins
|
|
189
194
|
|
|
190
195
|
---
|
|
@@ -198,6 +203,7 @@ Security Pro Pack is licensed for personal and commercial use. See LICENSE file
|
|
|
198
203
|
## Version History
|
|
199
204
|
|
|
200
205
|
**v1.0.0** (October 10, 2025)
|
|
206
|
+
|
|
201
207
|
- Initial release
|
|
202
208
|
- 10 plugins (5 agents, 5 commands)
|
|
203
209
|
- Full OWASP Top 10 coverage
|
|
@@ -206,6 +212,6 @@ Security Pro Pack is licensed for personal and commercial use. See LICENSE file
|
|
|
206
212
|
|
|
207
213
|
---
|
|
208
214
|
|
|
209
|
-
**Built with security in mind. Ship secure code with confidence.**
|
|
215
|
+
**Built with security in mind. Ship secure code with confidence.**
|
|
210
216
|
|
|
211
217
|
**Security Pro Pack Team**
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@intentsolutionsio/security-pro-pack",
|
|
3
|
-
"version": "1.0.
|
|
3
|
+
"version": "1.0.8",
|
|
4
4
|
"description": "Professional security tools for Claude Code: vulnerability scanning, compliance, cryptography audit, container & API security",
|
|
5
5
|
"keywords": [
|
|
6
6
|
"security",
|
|
@@ -1,13 +1,22 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: performing-security-audits
|
|
3
|
-
description:
|
|
4
|
-
|
|
3
|
+
description: 'Analyze code, infrastructure, and configurations by conducting comprehensive
|
|
4
|
+
security audits. It leverages tools within the security-pro-pack plugin, including
|
|
5
|
+
vulnerability scanning, compliance checking, and cryptography review. Use when assessing
|
|
6
|
+
security or running audits. Trigger with phrases like ''security scan'', ''audit'',
|
|
7
|
+
or ''vulnerability''.
|
|
8
|
+
|
|
9
|
+
'
|
|
5
10
|
allowed-tools: Read, Write, Edit, Grep, Glob, Bash(cmd:*)
|
|
6
11
|
version: 1.0.0
|
|
7
12
|
author: Jeremy Longshore <jeremy@intentsolutions.io>
|
|
8
13
|
license: MIT
|
|
9
|
-
|
|
10
|
-
|
|
14
|
+
tags:
|
|
15
|
+
- packages
|
|
16
|
+
- security
|
|
17
|
+
- compliance
|
|
18
|
+
- audit
|
|
19
|
+
compatibility: Designed for Claude Code, also compatible with Codex and OpenClaw
|
|
11
20
|
---
|
|
12
21
|
# Security Pro Pack
|
|
13
22
|
|
|
@@ -26,6 +35,7 @@ Perform in-depth security audits across various domains, from code vulnerability
|
|
|
26
35
|
## When to Use This Skill
|
|
27
36
|
|
|
28
37
|
This skill activates when you need to:
|
|
38
|
+
|
|
29
39
|
- Assess the security of code for vulnerabilities like those in the OWASP Top 10.
|
|
30
40
|
- Evaluate compliance with standards such as HIPAA, PCI DSS, GDPR, or SOC 2.
|
|
31
41
|
- Review cryptographic implementations for weaknesses.
|
|
@@ -38,6 +48,7 @@ This skill activates when you need to:
|
|
|
38
48
|
User request: "Please perform a security audit on this authentication code to find any potential vulnerabilities."
|
|
39
49
|
|
|
40
50
|
The skill will:
|
|
51
|
+
|
|
41
52
|
1. Invoke the `Security Auditor Expert` agent.
|
|
42
53
|
2. Analyze the provided authentication code for common vulnerabilities.
|
|
43
54
|
3. Generate a report detailing any identified vulnerabilities, their severity, and recommended fixes.
|
|
@@ -47,6 +58,7 @@ The skill will:
|
|
|
47
58
|
User request: "Check this application against GDPR compliance requirements."
|
|
48
59
|
|
|
49
60
|
The skill will:
|
|
61
|
+
|
|
50
62
|
1. Invoke the `Compliance Checker` agent.
|
|
51
63
|
2. Evaluate the application's architecture and code against GDPR guidelines.
|
|
52
64
|
3. Generate a report highlighting any non-compliant areas and suggesting necessary changes.
|
|
@@ -86,4 +98,4 @@ The skill produces structured output relevant to the task.
|
|
|
86
98
|
## Resources
|
|
87
99
|
|
|
88
100
|
- Project documentation
|
|
89
|
-
- Related skills and commands
|
|
101
|
+
- Related skills and commands
|
|
@@ -32,19 +32,19 @@
|
|
|
32
32
|
|
|
33
33
|
### 3.1. PCI DSS Requirement 3.2: Do not store sensitive authentication data after authorization (even if encrypted).
|
|
34
34
|
|
|
35
|
-
*
|
|
35
|
+
* **Finding:** The application stores the Card Verification Value (CVV) in the database after transaction processing.
|
|
36
36
|
|
|
37
|
-
*
|
|
37
|
+
* **Impact:** This violates PCI DSS requirement 3.2 and significantly increases the risk of data breach. Storing CVV data is strictly prohibited.
|
|
38
38
|
|
|
39
|
-
*
|
|
39
|
+
* **Recommendation:** Modify the application to prevent the storage of CVV data after authorization. CVV data should only be used for the initial transaction and then discarded. Implement processes to ensure no CVV data exists in the database and schedule regular audits to verify adherence.
|
|
40
40
|
|
|
41
41
|
### 3.2. [Compliance Standard] Requirement [Number]: [Requirement Description]
|
|
42
42
|
|
|
43
|
-
*
|
|
43
|
+
* **Finding:** [Detailed description of the non-compliance issue.]
|
|
44
44
|
|
|
45
|
-
*
|
|
45
|
+
* **Impact:** [Explanation of the potential consequences of the non-compliance issue.]
|
|
46
46
|
|
|
47
|
-
*
|
|
47
|
+
* **Recommendation:** [Specific steps to remediate the non-compliance issue.]
|
|
48
48
|
|
|
49
49
|
[Repeat the above structure for each finding related to the compliance standard being assessed.]
|
|
50
50
|
|
|
@@ -65,12 +65,12 @@
|
|
|
65
65
|
|
|
66
66
|
[List any supporting documentation used in the compliance assessment, such as:
|
|
67
67
|
|
|
68
|
-
*
|
|
69
|
-
*
|
|
70
|
-
*
|
|
71
|
-
*
|
|
72
|
-
*
|
|
73
|
-
*
|
|
68
|
+
* System architecture diagrams
|
|
69
|
+
* Configuration files
|
|
70
|
+
* Code review reports
|
|
71
|
+
* Vulnerability scan reports
|
|
72
|
+
* Policy documents
|
|
73
|
+
* Training records]
|
|
74
74
|
|
|
75
75
|
## 7. Assumptions and Limitations
|
|
76
76
|
|
|
@@ -78,4 +78,4 @@
|
|
|
78
78
|
|
|
79
79
|
## 8. Conclusion
|
|
80
80
|
|
|
81
|
-
[Provide a final summary of the compliance status and reiterate any key recommendations. For example: "While the [Project Name] project is currently considered *Partially Compliant*, addressing the findings outlined in this report will bring the project into full compliance with [Compliance Standard]. Continued monitoring and regular compliance assessments are recommended to maintain a strong security posture."]
|
|
81
|
+
[Provide a final summary of the compliance status and reiterate any key recommendations. For example: "While the [Project Name] project is currently considered *Partially Compliant*, addressing the findings outlined in this report will bring the project into full compliance with [Compliance Standard]. Continued monitoring and regular compliance assessments are recommended to maintain a strong security posture."]
|
|
@@ -12,11 +12,11 @@
|
|
|
12
12
|
|
|
13
13
|
## 2. Scan Details
|
|
14
14
|
|
|
15
|
-
*
|
|
16
|
-
*
|
|
17
|
-
*
|
|
18
|
-
*
|
|
19
|
-
*
|
|
15
|
+
* **Target:** `[Specify the target of the scan (e.g., repository URL, file path, container image name, API endpoint). Example: Repository: github.com/example/project]`
|
|
16
|
+
* **Scan Type:** `[Specify the type of scan performed (e.g., Static Analysis, Dynamic Analysis, Dependency Scan). Example: Static Analysis]`
|
|
17
|
+
* **Scanner Version:** `[Specify the version of the Security Pro Pack plugin and the underlying scanner used. Example: Security Pro Pack - Vulnerability Scanner v1.0.0 using Semgrep v1.10.0]`
|
|
18
|
+
* **Configuration:** `[Describe any custom configurations or settings used during the scan. If default settings were used, state that. Example: Default Semgrep ruleset was used.]`
|
|
19
|
+
* **Scan Duration:** `[Specify the total time taken to complete the scan. Example: 5 minutes 30 seconds]`
|
|
20
20
|
|
|
21
21
|
## 3. Vulnerability Findings
|
|
22
22
|
|
|
@@ -26,62 +26,62 @@ This section details the vulnerabilities identified during the scan. Each vulner
|
|
|
26
26
|
|
|
27
27
|
`[List all vulnerabilities classified as Critical. For each vulnerability, provide the following information:]`
|
|
28
28
|
|
|
29
|
-
*
|
|
30
|
-
*
|
|
31
|
-
*
|
|
32
|
-
*
|
|
33
|
-
*
|
|
34
|
-
*
|
|
35
|
-
*
|
|
29
|
+
* **Vulnerability ID:** `[Unique identifier for the vulnerability. Example: CRITICAL-001]`
|
|
30
|
+
* **Description:** `[Detailed explanation of the vulnerability and its potential impact. Example: SQL Injection vulnerability in the login form allows attackers to execute arbitrary SQL commands.]`
|
|
31
|
+
* **Severity:** **Critical**
|
|
32
|
+
* **Location:** `[Precise location of the vulnerability in the code or configuration. Example: src/auth/login.php: line 42]`
|
|
33
|
+
* **Affected Component:** `[Specify which component or module is affected. Example: Authentication Module]`
|
|
34
|
+
* **Recommendation:** `[Specific steps to remediate the vulnerability. Example: Implement parameterized queries or use an ORM to prevent SQL injection.]`
|
|
35
|
+
* **Evidence:** `[Provide evidence of the vulnerability, such as code snippets, request/response examples, or screenshots. Example: Code snippet showing the vulnerable SQL query.]`
|
|
36
36
|
|
|
37
37
|
### 3.2 High Vulnerabilities
|
|
38
38
|
|
|
39
39
|
`[List all vulnerabilities classified as High. For each vulnerability, provide the same information as in section 3.1.]`
|
|
40
40
|
|
|
41
|
-
*
|
|
42
|
-
*
|
|
43
|
-
*
|
|
44
|
-
*
|
|
45
|
-
*
|
|
46
|
-
*
|
|
47
|
-
*
|
|
41
|
+
* **Vulnerability ID:** `[Unique identifier for the vulnerability. Example: HIGH-002]`
|
|
42
|
+
* **Description:** `[Detailed explanation of the vulnerability and its potential impact. Example: Cross-Site Scripting (XSS) vulnerability allows attackers to inject malicious scripts into the website.]`
|
|
43
|
+
* **Severity:** **High**
|
|
44
|
+
* **Location:** `[Precise location of the vulnerability in the code or configuration. Example: public/js/comment.js: line 15]`
|
|
45
|
+
* **Affected Component:** `[Specify which component or module is affected. Example: Commenting System]`
|
|
46
|
+
* **Recommendation:** `[Specific steps to remediate the vulnerability. Example: Implement proper input validation and output encoding to prevent XSS.]`
|
|
47
|
+
* **Evidence:** `[Provide evidence of the vulnerability, such as code snippets, request/response examples, or screenshots. Example: Example of a malicious script being injected and executed.]`
|
|
48
48
|
|
|
49
49
|
### 3.3 Medium Vulnerabilities
|
|
50
50
|
|
|
51
51
|
`[List all vulnerabilities classified as Medium. For each vulnerability, provide the same information as in section 3.1.]`
|
|
52
52
|
|
|
53
|
-
*
|
|
54
|
-
*
|
|
55
|
-
*
|
|
56
|
-
*
|
|
57
|
-
*
|
|
58
|
-
*
|
|
59
|
-
*
|
|
53
|
+
* **Vulnerability ID:** `[Unique identifier for the vulnerability. Example: MEDIUM-003]`
|
|
54
|
+
* **Description:** `[Detailed explanation of the vulnerability and its potential impact. Example: Insecure Direct Object Reference (IDOR) allows users to access resources belonging to other users.]`
|
|
55
|
+
* **Severity:** **Medium**
|
|
56
|
+
* **Location:** `[Precise location of the vulnerability in the code or configuration. Example: src/profile/profile.php: line 28]`
|
|
57
|
+
* **Affected Component:** `[Specify which component or module is affected. Example: User Profile Module]`
|
|
58
|
+
* **Recommendation:** `[Specific steps to remediate the vulnerability. Example: Implement proper authorization checks to ensure users can only access their own resources.]`
|
|
59
|
+
* **Evidence:** `[Provide evidence of the vulnerability, such as code snippets, request/response examples, or screenshots. Example: Example of a user accessing another user's profile.]`
|
|
60
60
|
|
|
61
61
|
### 3.4 Low Vulnerabilities
|
|
62
62
|
|
|
63
63
|
`[List all vulnerabilities classified as Low. For each vulnerability, provide the same information as in section 3.1.]`
|
|
64
64
|
|
|
65
|
-
*
|
|
66
|
-
*
|
|
67
|
-
*
|
|
68
|
-
*
|
|
69
|
-
*
|
|
70
|
-
*
|
|
71
|
-
*
|
|
65
|
+
* **Vulnerability ID:** `[Unique identifier for the vulnerability. Example: LOW-004]`
|
|
66
|
+
* **Description:** `[Detailed explanation of the vulnerability and its potential impact. Example: Information leakage through error messages.]`
|
|
67
|
+
* **Severity:** **Low**
|
|
68
|
+
* **Location:** `[Precise location of the vulnerability in the code or configuration. Example: config/database.php]`
|
|
69
|
+
* **Affected Component:** `[Specify which component or module is affected. Example: Database Configuration]`
|
|
70
|
+
* **Recommendation:** `[Specific steps to remediate the vulnerability. Example: Disable detailed error messages in production environments.]`
|
|
71
|
+
* **Evidence:** `[Provide evidence of the vulnerability, such as code snippets, request/response examples, or screenshots. Example: Example of an error message revealing sensitive information.]`
|
|
72
72
|
|
|
73
73
|
## 4. Compliance Checks
|
|
74
74
|
|
|
75
75
|
`[If the scan included compliance checks, list the results here. Specify the compliance standard being checked (e.g., PCI DSS, HIPAA, GDPR) and the status of each requirement.]`
|
|
76
76
|
|
|
77
|
-
*
|
|
77
|
+
* **Compliance Standard:** `[Specify the compliance standard. Example: PCI DSS v3.2.1]`
|
|
78
78
|
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
79
|
+
* **Requirement 1.1.1:** `[Description of the requirement. Example: Establish and document security policies and operating procedures.]`
|
|
80
|
+
* **Status:** `[Pass/Fail. Example: Pass]`
|
|
81
|
+
* **Details:** `[Any relevant details about the compliance check. Example: Security policies and operating procedures are documented and reviewed annually.]`
|
|
82
|
+
* **Requirement 2.2.2:** `[Description of the requirement. Example: Implement and maintain a firewall configuration to protect cardholder data.]`
|
|
83
|
+
* **Status:** `[Pass/Fail. Example: Fail]`
|
|
84
|
+
* **Details:** `[Any relevant details about the compliance check. Example: Firewall rules are not properly configured to restrict access to cardholder data.]`
|
|
85
85
|
|
|
86
86
|
## 5. Recommendations
|
|
87
87
|
|
|
@@ -95,6 +95,6 @@ This section details the vulnerabilities identified during the scan. Each vulner
|
|
|
95
95
|
|
|
96
96
|
`[Include any additional information or supporting documentation, such as links to relevant resources or detailed scan logs. Example: Links to relevant security advisories and documentation on vulnerability remediation.]`
|
|
97
97
|
|
|
98
|
-
*
|
|
99
|
-
*
|
|
100
|
-
*
|
|
98
|
+
* Link to Security Advisories
|
|
99
|
+
* Link to Vulnerability Remediation Documentation
|
|
100
|
+
* [Detailed Scan Logs (Attached Separately)]
|
|
@@ -4,16 +4,16 @@ This template is designed to help you create a comprehensive threat model for yo
|
|
|
4
4
|
|
|
5
5
|
## 1. Introduction
|
|
6
6
|
|
|
7
|
-
*
|
|
8
|
-
*
|
|
9
|
-
*
|
|
10
|
-
*
|
|
11
|
-
*
|
|
7
|
+
* **Project Name:** [Enter Project Name Here]
|
|
8
|
+
* **Version:** [Enter Version Number Here]
|
|
9
|
+
* **Author(s):** [Enter Author(s) Here]
|
|
10
|
+
* **Date:** [Enter Date Here]
|
|
11
|
+
* **Purpose:** [Describe the purpose of this threat model. For example: "To identify potential security threats to the [Project Name] application and outline mitigation strategies."]
|
|
12
12
|
|
|
13
13
|
## 2. System Overview
|
|
14
14
|
|
|
15
|
-
*
|
|
16
|
-
*
|
|
15
|
+
* **Description:** [Provide a high-level description of the system. What does it do? What are its key components?]
|
|
16
|
+
* **Architecture Diagram:** [Include a diagram showing the system architecture. This could be a simple block diagram or a more detailed representation. Consider using Mermaid diagrams.]
|
|
17
17
|
|
|
18
18
|
```mermaid
|
|
19
19
|
graph LR
|
|
@@ -24,18 +24,18 @@ This template is designed to help you create a comprehensive threat model for yo
|
|
|
24
24
|
```
|
|
25
25
|
|
|
26
26
|
[Replace the above Mermaid diagram with your actual system architecture.]
|
|
27
|
-
*
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
|
|
31
|
-
|
|
32
|
-
*
|
|
27
|
+
* **Key Components:**
|
|
28
|
+
* [Component 1: Name, Description, Functionality]
|
|
29
|
+
* [Component 2: Name, Description, Functionality]
|
|
30
|
+
* [Component 3: Name, Description, Functionality]
|
|
31
|
+
* [...]
|
|
32
|
+
* **Data Flow:** [Describe how data flows through the system. Where does data originate? Where is it stored? How is it transformed?]
|
|
33
33
|
|
|
34
34
|
## 3. Threat Modeling Methodology
|
|
35
35
|
|
|
36
|
-
*
|
|
37
|
-
*
|
|
38
|
-
*
|
|
36
|
+
* **Methodology Used:** [Specify the threat modeling methodology used (e.g., STRIDE, PASTA, OCTAVE). If you're using a custom approach, describe it here.]
|
|
37
|
+
* **Assumptions:** [List any assumptions made during the threat modeling process. For example: "We assume that the underlying operating system is patched and up-to-date."]
|
|
38
|
+
* **Scope:** [Define the scope of the threat model. What parts of the system are included? What parts are excluded?]
|
|
39
39
|
|
|
40
40
|
## 4. Threat Identification
|
|
41
41
|
|
|
@@ -51,49 +51,49 @@ Use the following table to document identified threats. Feel free to add column
|
|
|
51
51
|
|
|
52
52
|
**Column Definitions:**
|
|
53
53
|
|
|
54
|
-
*
|
|
55
|
-
*
|
|
56
|
-
*
|
|
57
|
-
*
|
|
58
|
-
*
|
|
59
|
-
*
|
|
60
|
-
*
|
|
61
|
-
*
|
|
62
|
-
*
|
|
63
|
-
*
|
|
54
|
+
* **Threat ID:** A unique identifier for the threat.
|
|
55
|
+
* **Component:** The component of the system affected by the threat.
|
|
56
|
+
* **Threat Category:** The category of the threat (e.g., Injection, Authentication, Data Security, Availability). You can use STRIDE categories (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) as a starting point.
|
|
57
|
+
* **Threat Description:** A detailed description of the threat.
|
|
58
|
+
* **Impact:** The potential impact of the threat if it is realized (e.g., High, Medium, Low). Consider factors like data breach, service disruption, financial loss, and reputational damage.
|
|
59
|
+
* **Likelihood:** The likelihood of the threat being realized (e.g., High, Medium, Low). Consider factors like the attacker's skill level, the attractiveness of the target, and the presence of existing security controls.
|
|
60
|
+
* **Risk Rating:** The overall risk rating, typically calculated by multiplying Impact and Likelihood (e.g., High, Medium, Low).
|
|
61
|
+
* **Mitigation Strategy:** The proposed mitigation strategy to address the threat.
|
|
62
|
+
* **Status:** The current status of the mitigation strategy (e.g., Planned, In Progress, Completed, Reviewed).
|
|
63
|
+
* **Owner:** The individual or team responsible for implementing the mitigation strategy.
|
|
64
64
|
|
|
65
65
|
## 5. Data Flow Diagram (DFD) Analysis (Optional)
|
|
66
66
|
|
|
67
67
|
If a Data Flow Diagram (DFD) was created, include an analysis of potential threats at each stage of the data flow. This can supplement the table above.
|
|
68
68
|
|
|
69
|
-
*
|
|
70
|
-
|
|
71
|
-
|
|
72
|
-
|
|
73
|
-
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
*
|
|
77
|
-
|
|
69
|
+
* **Data Flow 1:** [Describe the data flow. e.g., User Login]
|
|
70
|
+
* **Process:** [Describe the process. e.g., User enters credentials on the login form.]
|
|
71
|
+
* **Potential Threats:** [List potential threats. e.g., Credential stuffing, XSS on the login page.]
|
|
72
|
+
* **Mitigation Strategies:** [List mitigation strategies. e.g., Rate limiting, input validation, output encoding.]
|
|
73
|
+
* **Data Store:** [Describe the data store. e.g., Database containing user credentials.]
|
|
74
|
+
* **Potential Threats:** [List potential threats. e.g., SQL injection, brute-force attack.]
|
|
75
|
+
* **Mitigation Strategies:** [List mitigation strategies. e.g., Parameterized queries, account lockout policy.]
|
|
76
|
+
* **Data Flow 2:** [Describe the data flow]
|
|
77
|
+
* [...]
|
|
78
78
|
|
|
79
79
|
## 6. Security Requirements
|
|
80
80
|
|
|
81
81
|
Based on the identified threats, define specific security requirements for the system.
|
|
82
82
|
|
|
83
|
-
*
|
|
84
|
-
|
|
85
|
-
*
|
|
86
|
-
|
|
87
|
-
*
|
|
88
|
-
|
|
83
|
+
* **Requirement 1:** [e.g., Implement multi-factor authentication for all user accounts.]
|
|
84
|
+
* **Justification:** [e.g., Mitigates the risk of unauthorized access due to compromised credentials.]
|
|
85
|
+
* **Requirement 2:** [e.g., Encrypt all sensitive data at rest and in transit.]
|
|
86
|
+
* **Justification:** [e.g., Protects data from unauthorized disclosure in case of a data breach.]
|
|
87
|
+
* **Requirement 3:** [e.g., Regularly scan the application for vulnerabilities.]
|
|
88
|
+
* **Justification:** [e.g., Identifies and addresses potential security flaws before they can be exploited.]
|
|
89
89
|
|
|
90
90
|
## 7. Conclusion
|
|
91
91
|
|
|
92
|
-
*
|
|
93
|
-
*
|
|
94
|
-
*
|
|
92
|
+
* **Summary of Findings:** [Summarize the key findings of the threat model.]
|
|
93
|
+
* **Recommendations:** [Provide recommendations for improving the security of the system.]
|
|
94
|
+
* **Next Steps:** [Outline the next steps to be taken, such as implementing the mitigation strategies and security requirements.]
|
|
95
95
|
|
|
96
96
|
## 8. Appendix (Optional)
|
|
97
97
|
|
|
98
|
-
*
|
|
99
|
-
*
|
|
98
|
+
* **Glossary of Terms:** [Define any technical terms used in the threat model.]
|
|
99
|
+
* **References:** [List any relevant references, such as security standards, best practices, or vendor documentation.]
|
|
@@ -5,12 +5,11 @@ Automates running various security scans (e.g., nmap, nessus) and parsing the re
|
|
|
5
5
|
Generated: 2025-12-10 03:48:17
|
|
6
6
|
"""
|
|
7
7
|
|
|
8
|
-
import os
|
|
9
8
|
import sys
|
|
10
9
|
import json
|
|
11
10
|
import argparse
|
|
12
11
|
from pathlib import Path
|
|
13
|
-
|
|
12
|
+
|
|
14
13
|
|
|
15
14
|
def process_file(file_path: Path) -> bool:
|
|
16
15
|
"""Process individual file."""
|
|
@@ -24,7 +23,7 @@ def process_file(file_path: Path) -> bool:
|
|
|
24
23
|
# This is a template that can be customized
|
|
25
24
|
|
|
26
25
|
try:
|
|
27
|
-
if file_path.suffix ==
|
|
26
|
+
if file_path.suffix == ".json":
|
|
28
27
|
with open(file_path) as f:
|
|
29
28
|
data = json.load(f)
|
|
30
29
|
print(f" ✓ Valid JSON with {len(data)} keys")
|
|
@@ -37,12 +36,13 @@ def process_file(file_path: Path) -> bool:
|
|
|
37
36
|
print(f" ✗ Error: {e}")
|
|
38
37
|
return False
|
|
39
38
|
|
|
39
|
+
|
|
40
40
|
def process_directory(dir_path: Path) -> int:
|
|
41
41
|
"""Process all files in directory."""
|
|
42
42
|
processed = 0
|
|
43
43
|
failed = 0
|
|
44
44
|
|
|
45
|
-
for file_path in dir_path.rglob(
|
|
45
|
+
for file_path in dir_path.rglob("*"):
|
|
46
46
|
if file_path.is_file():
|
|
47
47
|
if process_file(file_path):
|
|
48
48
|
processed += 1
|
|
@@ -51,28 +51,29 @@ def process_directory(dir_path: Path) -> int:
|
|
|
51
51
|
|
|
52
52
|
return processed, failed
|
|
53
53
|
|
|
54
|
+
|
|
54
55
|
def main():
|
|
55
56
|
parser = argparse.ArgumentParser(
|
|
56
57
|
description="Automates running various security scans (e.g., nmap, nessus) and parsing the results."
|
|
57
58
|
)
|
|
58
|
-
parser.add_argument(
|
|
59
|
-
parser.add_argument(
|
|
60
|
-
parser.add_argument(
|
|
61
|
-
parser.add_argument(
|
|
59
|
+
parser.add_argument("input", help="Input file or directory")
|
|
60
|
+
parser.add_argument("--output", "-o", help="Output directory")
|
|
61
|
+
parser.add_argument("--verbose", "-v", action="store_true", help="Verbose output")
|
|
62
|
+
parser.add_argument("--config", "-c", help="Configuration file")
|
|
62
63
|
|
|
63
64
|
args = parser.parse_args()
|
|
64
65
|
|
|
65
66
|
input_path = Path(args.input)
|
|
66
67
|
|
|
67
|
-
print(
|
|
68
|
-
print(
|
|
69
|
-
print(
|
|
68
|
+
print("🚀 security-pro-pack - security_scan.sh")
|
|
69
|
+
print(" Category: packages")
|
|
70
|
+
print(" Plugin: security-pro-pack")
|
|
70
71
|
print(f" Input: {input_path}")
|
|
71
72
|
|
|
72
73
|
if args.config:
|
|
73
74
|
if Path(args.config).exists():
|
|
74
75
|
with open(args.config) as f:
|
|
75
|
-
|
|
76
|
+
json.load(f)
|
|
76
77
|
print(f" Config: {args.config}")
|
|
77
78
|
|
|
78
79
|
# Process input
|
|
@@ -81,7 +82,7 @@ def main():
|
|
|
81
82
|
result = 0 if success else 1
|
|
82
83
|
elif input_path.is_dir():
|
|
83
84
|
processed, failed = process_directory(input_path)
|
|
84
|
-
print(
|
|
85
|
+
print("\n📊 SUMMARY")
|
|
85
86
|
print(f" ✅ Processed: {processed}")
|
|
86
87
|
print(f" ❌ Failed: {failed}")
|
|
87
88
|
result = 0 if failed == 0 else 1
|
|
@@ -96,5 +97,6 @@ def main():
|
|
|
96
97
|
|
|
97
98
|
return result
|
|
98
99
|
|
|
100
|
+
|
|
99
101
|
if __name__ == "__main__":
|
|
100
102
|
sys.exit(main())
|