원클릭으로 Manus에서 모든 스킬 실행

implementing-runtime-application-self-protection

스타680

포크120

업데이트2026년 6월 6일 16:41

Deploy Runtime Application Self-Protection (RASP) agents to detect and block attacks from within application runtime, covering OpenRASP integration, attack pattern detection, and security policy configuration for Java and Python web applications.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

xalgord

xalgord/xalgorix

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Implementing Runtime Application Self-Protection

Overview

Runtime Application Self-Protection (RASP) instruments application code at runtime to detect and block attacks by examining actual execution context rather than relying solely on network traffic patterns. Unlike WAFs that inspect HTTP requests externally, RASP agents intercept dangerous operations (SQL queries, file operations, command execution, deserialization) at the function level inside the application, achieving near-zero false positives. This skill covers deploying OpenRASP for Java applications, configuring detection policies for OWASP Top 10 attacks, tuning alerting thresholds, and integrating RASP telemetry with SIEM platforms.

When to Use

When deploying or configuring implementing runtime application self protection capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation

Common Misconfigurations & Verification

RASP that is installed but left in monitor mode gives a false sense of protection — it logs attacks it never stops.

Stuck in monitor/detect-only: OpenRASP policies left at action: log (or inspect) after the tuning phase never call block. Confirm each policy for SQLi, command injection, SSRF, path traversal, XXE, and deserialization is set to block in production.
Excluded or un-instrumented routes: the JVM -javaagent attaches but a separately-deployed service, async worker, or native/JNI path is not hooked, leaving a coverage hole. Verify every entry point loads the agent (check startup logs for the RASP banner).
Over-broad allowlists: tuning to kill false positives by whitelisting whole endpoints disables protection on exactly the routes that take user input.
Telemetry not reaching SIEM: block events fire but the Splunk HEC / syslog forwarder is misconfigured, so nobody sees them.

Verify with live payloads, not config review: in staging, send a real SQLi (' OR 1=1--), an OS command-injection (; id), and a path-traversal (../../etc/passwd) against an instrumented endpoint and confirm the request is blocked (HTTP 403/500) with a matching stack-trace alert in the SIEM. A logged-but-served request means the agent is still monitor-only.

Prerequisites

Java 8+ application server (Tomcat, Spring Boot, or JBoss) or Python Flask/Django application
OpenRASP agent package (rasp-java or equivalent)
OpenRASP management console for centralized policy management
SIEM integration endpoint (Splunk HEC, Elasticsearch, or syslog)
Application staging environment for RASP testing before production

Steps

Step 1: Deploy RASP Agent

Install the RASP agent into the application server runtime using JVM agent attachment for Java or middleware hooks for Python.

Step 2: Configure Detection Policies

Define detection rules for SQL injection, command injection, SSRF, path traversal, XXE, and deserialization attacks with block or monitor actions.

Step 3: Tune and Baseline

Run the agent in monitor mode during normal operations to establish baseline behavior and tune policies to reduce false positives before switching to block mode.

Step 4: Integrate with SIEM

Forward RASP alerts to the SIEM for correlation with WAF, IDS, and authentication events to build comprehensive attack timelines.

Expected Output

JSON report containing RASP policy audit results, detected attack attempts with stack traces, blocked requests summary, and coverage assessment against OWASP Top 10.

이 저장소의 다른 Skills

같은 저장소

exploiting-subdomain-takeover-vulnerabilities

xalgord/xalgorix

Identifying and exploiting dangling DNS records pointing to unclaimed cloud services, enabling subdomain takeover for phishing, cookie stealing, and authentication bypass during authorized penetration tests.

2026-06-19680

detecting-ai-model-prompt-injection-attacks

xalgord/xalgorix

Detects prompt injection attacks targeting LLM-based applications using a multi-layered defense combining regex pattern matching for known attack signatures, heuristic scoring for structural anomalies, and transformer-based classification with DeBERTa models. The detector analyzes user inputs before they reach the LLM, flagging direct injections (system prompt overrides, role-play escapes, instruction hijacking) and indirect injections (encoded payloads, multi-language obfuscation, delimiter-based escapes). Based on the OWASP LLM Top 10 (LLM01:2025 Prompt Injection) and Simon Willison's prompt injection taxonomy. Activates for requests involving prompt injection detection, LLM input sanitization, AI security scanning, or prompt attack classification.

2026-06-06680

exploiting-ai-model-file-rce

xalgord/xalgorix

Testing machine-learning model files and model-loading services for remote code execution caused by insecure deserialization (pickle/PyTorch), unsafe config instantiation (Hydra), archive path traversal, and dangerous layer types during authorized penetration tests of AI/ML pipelines.

2026-06-06680

implementing-llm-guardrails-for-security

xalgord/xalgorix

Implements input and output validation guardrails for LLM-powered applications to prevent prompt injection, data leakage, toxic content generation, and hallucinated outputs. Builds a security validation pipeline using NVIDIA NeMo Guardrails Colang definitions, custom Python validators for PII detection and content policy enforcement, and the Guardrails AI framework for structured output validation. The guardrails system intercepts both user inputs (blocking injection attempts, stripping PII, enforcing topic boundaries) and model outputs (detecting hallucinations, filtering toxic content, validating JSON schema compliance). Activates for requests involving LLM output validation, AI content filtering, guardrail implementation, or LLM safety enforcement.

2026-06-06680

performing-ai-assisted-vulnerability-discovery

xalgord/xalgorix

Using LLMs to accelerate vulnerability research and pentest workflows — generating syntax-valid fuzzing seeds and evolving grammars, fine-tuned mutation dictionaries, parallel agent-based proof-of-vulnerability generation, and evidence-driven passive analysis of real HTTP traffic via the Burp MCP server. Covers concrete prompts, AFL++/ libFuzzer wiring, and Burp+Codex/Gemini/Ollama MCP setup.

2026-06-06680

testing-llm-prompt-injection-and-jailbreaks

xalgord/xalgorix

Testing LLM-backed applications, chatbots, and AI agents for direct and indirect prompt injection, jailbreaks, system-prompt leakage, and tool/agent abuse during authorized penetration tests, using structured payload families and reliable confirmation signals.

2026-06-06680

name	implementing-runtime-application-self-protection
description	Deploy Runtime Application Self-Protection (RASP) agents to detect and block attacks from within application runtime, covering OpenRASP integration, attack pattern detection, and security policy configuration for Java and Python web applications.
domain	cybersecurity
subdomain	application-security
tags	["rasp","application-security","openrasp","runtime-protection","sqli","xss","rce","devsecops"]
version	1.0
author	mahipal
license	Apache-2.0
nist_ai_rmf	["GOVERN-1.1","MEASURE-2.7","MANAGE-3.1"]
nist_csf	["PR.PS-01","PR.PS-04","ID.RA-01","PR.DS-10"]

Implementing Runtime Application Self-Protection

Overview

When to Use

When deploying or configuring implementing runtime application self protection capabilities in your environment
When establishing security controls aligned to compliance requirements
When building or improving security architecture for this domain
When conducting security assessments that require this implementation

Common Misconfigurations & Verification

RASP that is installed but left in monitor mode gives a false sense of protection — it logs attacks it never stops.

Stuck in monitor/detect-only: OpenRASP policies left at action: log (or inspect) after the tuning phase never call block. Confirm each policy for SQLi, command injection, SSRF, path traversal, XXE, and deserialization is set to block in production.
Excluded or un-instrumented routes: the JVM -javaagent attaches but a separately-deployed service, async worker, or native/JNI path is not hooked, leaving a coverage hole. Verify every entry point loads the agent (check startup logs for the RASP banner).
Over-broad allowlists: tuning to kill false positives by whitelisting whole endpoints disables protection on exactly the routes that take user input.
Telemetry not reaching SIEM: block events fire but the Splunk HEC / syslog forwarder is misconfigured, so nobody sees them.

Prerequisites

Java 8+ application server (Tomcat, Spring Boot, or JBoss) or Python Flask/Django application
OpenRASP agent package (rasp-java or equivalent)
OpenRASP management console for centralized policy management
SIEM integration endpoint (Splunk HEC, Elasticsearch, or syslog)
Application staging environment for RASP testing before production

Steps

Step 1: Deploy RASP Agent

Install the RASP agent into the application server runtime using JVM agent attachment for Java or middleware hooks for Python.

Step 2: Configure Detection Policies

Define detection rules for SQL injection, command injection, SSRF, path traversal, XXE, and deserialization attacks with block or monitor actions.

Step 3: Tune and Baseline

Run the agent in monitor mode during normal operations to establish baseline behavior and tune policies to reduce false positives before switching to block mode.

Step 4: Integrate with SIEM

Forward RASP alerts to the SIEM for correlation with WAF, IDS, and authentication events to build comprehensive attack timelines.

Expected Output

JSON report containing RASP policy audit results, detected attack attempts with stack traces, blocked requests summary, and coverage assessment against OWASP Top 10.