القائمة
Apply compiler hardening flags and sanitizers to C/C++ builds. Use when reviewing build configurations, CI pipelines, or Makefiles/CMakeLists for native code projects.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Security-focused review of AI-generated or AI-assisted code. Use when reviewing code produced by AI coding assistants, auditing AI-generated patches, verifying AI-assisted contributions before merge, or when a review needs to account for failure modes specific to AI code generation.
Configure Kubernetes network security including host access restrictions, network policies, port management, and connectivity requirements. Use when writing, reviewing, or auditing pod specs, Services, NetworkPolicies, or NetworkAttachmentDefinitions.
Secure AI-powered products and infrastructure. Use when integrating LLM APIs, deploying model-serving infrastructure, building agent workflows, connecting MCP servers, or reviewing AI system architecture for security gaps.
Enforce standard authentication for external data source connections. Use when integrating, configuring, or reviewing connections from AI systems to external databases, APIs, or data services.
Harden container images and runtime configuration. Use when building, reviewing, or auditing Containerfiles, Dockerfiles, container compose files, or Kubernetes pod security settings.
Supply chain security audit using CLI vulnerability scanners, license compliance checks, and supply chain risk assessment. Use when auditing project dependencies for known CVEs, license concerns, and supply chain health.
| name | compiler-hardening |
| description | Apply compiler hardening flags and sanitizers to C/C++ builds. Use when reviewing build configurations, CI pipelines, or Makefiles/CMakeLists for native code projects. |
| category | secure_development |
| subcategory | languages |
| Category | Examples |
|---|---|
| Memory errors | Buffer overflow, use-after-free (UAF), buffer over-read |
| Dependency attacks | Library hijacking, library sideloading, supply chain compromise |
When building with Fedora/RPM toolchains, hardened flags are often applied automatically. For other build systems, explicitly add hardening options.
The OpenSSF Compiler Hardening Guide is the canonical reference. Key flags include:
| Flag | Purpose |
|---|---|
-fstack-protector-strong | Stack buffer overflow detection |
-D_FORTIFY_SOURCE=2 | Runtime buffer overflow checks for standard library functions |
-fPIE / -pie | Position-independent executable for ASLR |
-Wl,-z,relro,-z,now | Full RELRO -- makes GOT read-only after relocation |
-Wl,-z,noexecstack | Non-executable stack |
-fno-strict-overflow | Prevent undefined behavior optimizations on signed overflow |
GCC 14+ provides -fhardened as a convenience flag that enables a recommended set of hardening options.
The Fedora Security Features Matrix provides an overview of security features available in a modern Linux system.
Sanitizers add runtime instrumentation that catches errors during testing that would otherwise go undetected. They increase binary size and resource consumption but provide significantly better error detection and debug information than traditional tooling.
| Sanitizer | Flag | Detects |
|---|---|---|
| AddressSanitizer | -fsanitize=address | Memory access violations (buffer overflow, UAF, stack overflow) |
| ThreadSanitizer | -fsanitize=thread | Data races and race conditions |
| LeakSanitizer | -fsanitize=leak | Memory leaks |
| UndefinedBehaviorSanitizer | -fsanitize=undefined | Undefined behavior at runtime |
Run sanitizer-enabled builds in CI. ASan and UBSan are the highest-value sanitizers for most projects.
JIT compilers inherently conflict with W^X (write XOR execute) because they must generate executable code at runtime. W^X protections apply at page granularity and cannot be meaningfully enforced on JIT buffers. Other memory areas (thread stacks, heap) should still have NX (non-executable) protection.
User-space sandboxing alone is insufficient; prefer OS and process-level isolation (namespaces, seccomp, SELinux) as the primary security boundary. User-space sandboxes can serve as defense-in-depth but have historically introduced their own security bugs and should not be the sole barrier, especially post-Spectre.
Dynamic linking relies on well-known search paths and filesystem permissions. The compilation environment may differ from the runtime environment with different (but compatible) library versions. Review and mitigate:
LD_LIBRARY_PATH, RPATH manipulation)-fhardened with GCC 14+)-fstack-protector-strong is enabled_FORTIFY_SOURCE=2 is defined-fPIE -pie)-Wl,-z,relro,-z,now)