Generic security configuration naming

When implementing security-related configuration options, use generic, implementation-agnostic naming conventions rather than tying them to specific tools or runtimes. This approach ensures flexibility as the underlying technology stack evolves and prevents vendor lock-in in security configurations.

For example, when adding container security flags, prefer generic names like SANDBOX_FLAGS over tool-specific names like DOCKER_RUN_FLAGS. This allows the same configuration to work across different container runtimes (Docker, Podman, etc.) without requiring changes to user configurations.

Example:

# Good: Generic naming that works across container runtimes
export SANDBOX_FLAGS="--security-opt label=disable"

# Avoid: Tool-specific naming that limits flexibility  
export DOCKER_RUN_FLAGS="--security-opt label=disable"

This principle is especially important for security configurations because:

• Security policies should remain consistent regardless of the underlying implementation
• Teams may need to switch between different tools for security or compliance reasons
• Generic naming makes security configurations more maintainable and self-documenting

When reviewing security-related configuration code, ensure that environment variables, configuration keys, and API parameters use descriptive, generic names that reflect their security purpose rather than the specific tool being configured.