Skip to main content الرئيسية المنشئون oyi77 1ai-skills performing-web-application-vulnerability-triage
performing-web-application-vulnerability-triage Triage web application vulnerability findings from DAST/SAST scanners using OWASP risk rating methodology to separate true positives from false positives and prioritize remediation. Use when working with performing web application vulnerability triage.
الانتقال إلى التثبيت سوق المهارات اكتشف واستكشف مهارات الذكاء الاصطناعي التي بناها المجتمع.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
عرض تفاصيل Prompt يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/oyi77/1ai-skills --skill performing-web-application-vulnerability-triageيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
تحميل Zip جاري التحميل... المهن ذات الصلة SOC
استنادا إلى تصنيف SOC المهني
name performing-web-application-vulnerability-triage description Triage web application vulnerability findings from DAST/SAST scanners using OWASP risk rating methodology to separate true positives from false positives and prioritize remediation. Use when working with performing web application vulnerability triage. domain cybersecurity subdomain vulnerability-management tags ["web-application","vulnerability-triage","owasp","dast","sast","burp-suite","zap","false-positive","risk-rating"] version 1.0 author oyi77 license Apache-2.0 nist_csf ["ID.RA-01","ID.RA-02","ID.IM-02","ID.RA-06"]
Performing Web Application Vulnerability Triage
Overview
Web application vulnerability triage is the process of reviewing findings from DAST (Dynamic Application Security Testing) and SAST (Static Application Security Testing) tools to validate true positives, dismiss false positives, assign risk ratings using the OWASP Risk Rating Methodology, and prioritize remediation. Effective triage reduces alert fatigue and focuses development teams on the vulnerabilities that matter most.
When to Use
Trigger phrases:
"performing web application vulnerability triage"
"Triage web application vulnerability findings from DAST/SAST scanners using OWAS"
When conducting security assessments that involve performing web application vulnerability triage
When following incident response procedures for related security events
When performing scheduled security testing or auditing activities
When validating security controls through hands-on testing
Prerequisites
DAST scan results (OWASP ZAP, Burp Suite, Acunetix)
SAST scan results (Semgrep, SonarQube, Checkmarx, Snyk Code)
Python 3.9+ with requests, beautifulsoup4
Burp Suite Professional or OWASP ZAP for manual validation
DefectDojo or similar for finding management
OWASP Risk Rating Methodology
This section covers owasp risk rating methodology for performing web application vulnerability triage.
Ensure all prerequisites are met before proceeding
Follow the documented workflow steps in sequence
Record results and any anomalies encountered during this phase
Risk Calculation
Risk = Likelihood x Impact
Likelihood Factors (0-9 scale)
Factor Group Factor Description Threat Agent Skill Level How technically skilled is the attacker? Threat Agent Motive How motivated is the attacker? Threat Agent Opportunity What resources/access are needed? Threat Agent Size How large is the potential threat agent group?
How easy is it to find the vulnerability?
Vulnerability Ease of Exploit How easy is it to exploit?
Vulnerability Awareness How well known is the vulnerability?
Vulnerability Intrusion Detection How likely is exploitation to be detected?
Impact Factors (0-9 scale) Factor Group Factor Description Technical Confidentiality How much data could be disclosed? Technical Integrity How much data could be corrupted? Technical Availability How much service could be lost? Technical Accountability Can actions be traced to attacker? Business Financial Damage Revenue loss, regulatory fines Business Reputation Damage Brand trust erosion Business Non-compliance Regulatory violation exposure Business Privacy Violation PII/PHI exposure volume
Risk Matrix Low Impact (0-3) Medium Impact (3-6) High Impact (6-9) High Likelihood (6-9) Medium High Critical Medium Likelihood (3-6) Low Medium High Low Likelihood (0-3) Note Low Medium
Triage Process
Scope the task — define objectives, boundaries, and success criteriaGather information — collect all necessary data and context before proceedingExecute the core workflow — follow the domain-specific steps methodicallyValidate results — verify outputs against expected outcomes or baselinesDocument findings — record results, anomalies, and recommendations
Step 1: Categorize by OWASP Top 10 OWASP_TOP_10_2021 = {
"A01" : "Broken Access Control" ,
"A02" : "Cryptographic Failures" ,
"A03" : "Injection" ,
"A04" : "Insecure Design" ,
"A05" : "Security Misconfiguration" ,
"A06" : "Vulnerable and Outdated Components" ,
"A07" : "Identification and Authentication Failures" ,
"A08" : "Software and Data Integrity Failures" ,
"A09" : "Security Logging and Monitoring Failures" ,
"A10" : "Server-Side Request Forgery" ,
}
CWE_TO_OWASP = {
"CWE-79" : "A03" ,
"CWE-89" : "A03" ,
"CWE-78" : "A03" ,
"CWE-352" : "A01" ,
"CWE-22" : "A01" ,
"CWE-200" : "A02" ,
"CWE-327" : "A02" ,
"CWE-287" : "A07" ,
"CWE-918" : "A10" ,
"CWE-502" : "A08" ,
"CWE-611" : "A05" ,
}
Step 2: Validate True vs False Positives def triage_finding (finding ):
"""Classify finding as true_positive, false_positive, or needs_review."""
fp_indicators = [
"Content-Security-Policy header not set" ,
"X-Content-Type-Options header missing" ,
"Cookie without SameSite attribute" ,
]
for indicator in fp_indicators:
if indicator.lower() in finding.get("title" , "" ).lower():
if finding.get("severity" , "" ).lower() in ("info" , "low" ):
return "false_positive" , "Common informational finding"
if finding.get("evidence" ) and finding.get("confidence" , "" ).lower() == "certain" :
return "true_positive" , "Scanner confirmed exploitation"
if finding.get("source" ) == "sast" :
if finding.get("cwe" ) in ["CWE-89" , "CWE-78" , "CWE-79" ]:
return "needs_review" , "Injection finding requires manual code review"
return "needs_review" , "Requires manual validation"
Step 3: Risk Score Calculation def calculate_risk_score (finding, app_context ):
"""Calculate OWASP risk rating for a web application finding."""
likelihood = {
"skill_level" : 6 if finding["cwe" ] in ["CWE-89" , "CWE-79" ] else 4 ,
"motive" : 7 ,
"opportunity" : 7 if finding.get("authenticated" ) == False else 4 ,
"size" : 9 if finding.get("internet_facing" ) else 4 ,
"ease_of_discovery" : 8 if finding.get("scanner_detected" ) else 5 ,
"ease_of_exploit" : 7 if finding.get("exploit_available" ) else 4 ,
"awareness" : 6 ,
"intrusion_detection" : 3 if app_context.get("waf_enabled" ) else 8 ,
}
impact = {
"confidentiality" : 9 if "data_exposure" in finding.get("tags" , []) else 5 ,
"integrity" : 9 if finding["cwe" ] in ["CWE-89" , "CWE-78" ] else 4 ,
"availability" : 7 if "dos" in finding.get("tags" , []) else 2 ,
"accountability" : 3 if app_context.get("logging_enabled" ) else 7 ,
"financial" : 7 if app_context.get("processes_payments" ) else 3 ,
"reputation" : 6 if app_context.get("customer_facing" ) else 2 ,
"compliance" : 8 if app_context.get("pci_scope" ) else 3 ,
"privacy" : 9 if app_context.get("handles_pii" ) else 2 ,
}
likelihood_score = sum (likelihood.values()) / len (likelihood)
impact_score = sum (impact.values()) / len (impact)
risk_score = likelihood_score * impact_score
if risk_score >= 42 :
risk_level = "Critical"
elif risk_score >= 24 :
risk_level = "High"
elif risk_score >= 12 :
risk_level = "Medium"
elif risk_score >= 3 :
risk_level = "Low"
else :
risk_level = "Note"
return {
"likelihood_score" : round (likelihood_score, 1 ),
"impact_score" : round (impact_score, 1 ),
"risk_score" : round (risk_score, 1 ),
"risk_level" : risk_level,
}
Step 4: Generate Triage Report
python3 scripts/process.py \
--input zap_results.json \
--format zap \
--app-context app_config.json \
--output triage_report.json
Manual Validation Techniques This section covers manual validation techniques for performing web application vulnerability triage.
Ensure all prerequisites are met before proceeding
Follow the documented workflow steps in sequence
Record results and any anomalies encountered during this phase
SQL Injection Validation # Test parameter with single quote
GET /search?q=test' HTTP/1.1
# Test with boolean-based payload
GET /search?q=test' AND 1=1-- HTTP/1.1
GET /search?q=test' AND 1=2-- HTTP/1.1
# Time-based verification
GET /search?q=test'; WAITFOR DELAY '0:0:5'-- HTTP/1.1
XSS Validation # Reflected XSS test
GET /search?q=<script>alert(document.domain)</script> HTTP/1.1
# Check if output is encoded
GET /search?q="><img src=x onerror=alert(1)> HTTP/1.1
# DOM-based XSS
GET /page#<img src=x onerror=alert(1)> HTTP/1.1
When NOT to Use
You don't have explicit written authorization to test
Task is about defense/detection, not offense (use detection skills)
You need to implement security controls (use implementing-* skills)
Task requires compliance auditing (use auditing-* skills)
You're investigating an incident (use incident response skills)
Target is out of scope for your engagement
Task is about vulnerability scanning only (use scanning tools)
Red Flags
Performing actions without explicit written authorization from the asset owner
Testing against production systems without a defined scope and rules of engagement
Destroying potential evidence during the containment phase
Failing to document the chain of custody for all collected artifacts
Communicating incident details over unencrypted or monitored channels
Verification
All steps executed successfully against a test environment before production use
Output documented with screenshots or logs demonstrating expected behavior
Timeline of events reconstructed with corroborating evidence
Root cause identified and documented with contributing factors
Post-incident review completed with lessons learned and action items
References
Process
Analyze the task requirements
Apply domain expertise
Verify output quality
Anti-Rationalization Table Rationalization Reality "We are too small to be targeted" Automated attacks target everyone. Size does not matter. "Security slows us down" A breach slows you down 100x more. Build security in from the start. "We will fix it after launch" Vulnerabilities in production are exploited within hours. Fix before deploy.
