chore(deps): bump actions/upload-artifact from 3 to 4#6
Closed
dependabot[bot] wants to merge 1 commit into
Closed
Conversation
Bumps [actions/upload-artifact](https://github.com/actions/upload-artifact) from 3 to 4. - [Release notes](https://github.com/actions/upload-artifact/releases) - [Commits](actions/upload-artifact@v3...v4) --- updated-dependencies: - dependency-name: actions/upload-artifact dependency-version: '4' dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
Contributor
Author
LabelsThe following labels could not be found: Please fix the above issues or remove invalid values from |
Contributor
Author
|
Looks like actions/upload-artifact is up-to-date now, so this is no longer needed. |
dependabot
Bot
deleted the
dependabot/github_actions/actions/upload-artifact-4
branch
remyluslosius
added a commit
that referenced
this pull request
Oct 1, 2025
- Add comprehensive RuleParsingService for executing unified compliance rules - Support 8 rule types: command execution, file check, config parsing, service status, package check, permission check, content match, and composite - Add RuleOrchestratorService for executing rule sets and compliance profiles - Implement platform detection for RHEL 8/9, Ubuntu 20.04/22.04/24.04, CentOS, Debian - Support multiple configuration file formats: INI, JSON, dconf, key-value - Add parameter substitution and template processing capabilities - Comprehensive compliance checking with 8 comparison operators (eq, gt, lt, contains, regex, etc.) - Evidence collection and artifact management for audit trails - Framework-specific result generation with justification engine - Comprehensive test suite with integration scenarios for session lock and FIPS crypto rules Key Features: - Asynchronous rule execution with timeout handling and error recovery - Multi-framework result mapping with enhancement descriptions for exceeding compliance - Platform compatibility filtering and version range support - Concurrent rule execution with configurable parallelism limits - Sequential execution with dependency ordering support - Critical rule validation and threshold checking - Comprehensive error handling and execution statistics Technical Implementation: - Subprocess execution with environment variable support - Configuration file parsing for multiple formats (INI, dconf, JSON, key-value) - Service status checking via systemctl integration - Package management support for RPM and DEB-based systems - File permission and content matching with regex support - Platform detection via /etc/os-release parsing - Evidence artifacts and compliance justification generation 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
10 tasks
remyluslosius
added a commit
that referenced
this pull request
Oct 15, 2025
…Routing
Implements complete scan orchestration system that routes compliance checks
to appropriate scanners (OSCAP, Kubernetes, cloud APIs) and stores results
in MongoDB.
## New Components
### 1. MongoDB Models (scan_models.py - 280 lines)
- **ScanResult**: Complete scan execution record with rule-level results
- **ScanConfiguration**: Scan settings (target, framework, variables)
- **RuleResult**: Individual rule check result with status and message
- **ScanResultSummary**: Aggregated statistics (pass/fail/error counts)
- **ScanTarget**: Target system definition (SSH host, K8s cluster, cloud account)
- **ScanSchedule**: Future enhancement for recurring scans
### 2. Scanner Interface (base_scanner.py - 180 lines)
- **BaseScanner**: Abstract base class for all scanners
- **scan()**: Execute compliance checks against target
- **_calculate_summary()**: Aggregate rule results into summary
- **_group_by_severity()**: Breakdown by high/medium/low
- **_group_by_scanner()**: Breakdown by scanner type
- Custom exceptions: ScannerNotAvailableError, ScannerExecutionError
### 3. OSCAP Scanner (oscap_scanner.py - 380 lines)
- **OSCAPScanner**: Traditional OVAL-based compliance scanning
- Generates XCCDF benchmark from MongoDB rules
- Creates tailoring files for variable overrides
- Executes oscap (local) or oscap-ssh (remote)
- Parses XCCDF results XML into RuleResult objects
- Supports SSH-based remote scanning
### 4. Kubernetes Scanner (kubernetes_scanner.py - 280 lines)
- **KubernetesScanner**: YAML-based checks for K8s/OpenShift
- Queries Kubernetes API using kubectl + JSONPath
- Evaluates conditions: equals, not_equals, contains, exists, any_exist
- Supports OpenShift-specific resources (image.config.openshift.io)
- Compatible with kubeconfig-based authentication
### 5. Scanner Factory (scanners/__init__.py - 60 lines)
- **ScannerFactory**: Registry and factory for scanner instances
- get_scanner(scanner_type): Create scanner on demand
- register_scanner(): Plugin support for custom scanners
- Available scanners: oscap, kubernetes (more coming: aws_api, azure_api, gcp_api)
### 6. Scan Orchestrator (scan_orchestrator_service.py - 280 lines)
- **ScanOrchestrator**: Central coordinator for multi-scanner execution
- execute_scan(): Main entry point for scan execution
- Queries MongoDB for rules matching framework/version
- Groups rules by scanner_type
- Executes scanners in parallel with asyncio.gather()
- Aggregates results from all scanners
- Stores complete results in MongoDB
### 7. Scan API Endpoints (scans_api.py - 220 lines)
- **POST /api/v1/scans/execute**: Execute compliance scan
- **GET /api/v1/scans/{scan_id}**: Get scan result details
- **GET /api/v1/scans**: List scans with filters (status, pagination)
- **DELETE /api/v1/scans/{scan_id}**: Delete scan result
- **GET /api/v1/scans/statistics/summary**: Aggregated scan statistics
## Scan Execution Flow
```
1. User submits ScanConfiguration via API
↓
2. ScanOrchestrator queries MongoDB for rules
↓
3. Rules grouped by scanner_type:
- oscap: 45 rules
- kubernetes: 12 rules
↓
4. Scanners execute in parallel:
├─ OSCAPScanner:
│ ├─ Generate XCCDF benchmark
│ ├─ Generate tailoring file (if variables provided)
│ ├─ Execute oscap-ssh on target
│ └─ Parse results XML → RuleResults
│
└─ KubernetesScanner:
├─ For each rule:
│ ├─ Query K8s API via kubectl
│ ├─ Evaluate condition
│ └─ Create RuleResult
└─ Return results
↓
5. Orchestrator aggregates results:
- Combine all RuleResults
- Calculate summary statistics
- Store in MongoDB
↓
6. Return ScanResult to user
```
## Scanner Capabilities
| Scanner | Target Types | Capabilities | Status |
|---------|-------------|--------------|--------|
| oscap | SSH host, local | OVAL checks, XCCDF variables, tailoring | ✅ Implemented |
| kubernetes | K8s cluster | YAML checks, JSONPath queries, API access | ✅ Implemented |
| aws_api | AWS account | S3, IAM, VPC compliance | 🔜 Planned |
| azure_api | Azure subscription | Resource Manager checks | 🔜 Planned |
| gcp_api | GCP project | Cloud API checks | 🔜 Planned |
## Usage
### Execute Scan via API
```bash
curl -X POST http://localhost:8000/api/v1/scans/execute \\
-H "Authorization: Bearer $TOKEN" \\
-H "Content-Type: application/json" \\
-d '{
"target": {
"type": "ssh_host",
"identifier": "prod-web-01.example.com",
"credentials": {"username": "root"}
},
"framework": "nist",
"framework_version": "800-53r5",
"variable_overrides": {
"xccdf_com.hanalyx.openwatch_value_var_accounts_tmout": "300"
}
}'
```
### Check Scan Status
```bash
curl http://localhost:8000/api/v1/scans/{scan_id} \\
-H "Authorization: Bearer $TOKEN"
```
### Response
```json
{
"scan_id": "a1b2c3d4-...",
"status": "completed",
"started_at": "2025-10-15T08:00:00Z",
"completed_at": "2025-10-15T08:05:23Z",
"duration_seconds": 323.5,
"summary": {
"total_rules": 57,
"passed": 45,
"failed": 10,
"error": 2,
"compliance_percentage": 81.8,
"by_severity": {
"high": {"total": 15, "passed": 10, "failed": 5},
"medium": {"total": 30, "passed": 28, "failed": 2},
"low": {"total": 12, "passed": 7, "failed": 3}
},
"by_scanner": {
"oscap": {"total": 45, "passed": 35, "failed": 8},
"kubernetes": {"total": 12, "passed": 10, "failed": 2}
}
}
}
```
## Implementation Details
### Variable Override Application
OSCAP scanner generates tailoring files:
```xml
<xccdf:Tailoring>
<xccdf:Profile id="customized" extends="nist_800_53_r5">
<xccdf:set-value idref="xccdf_...value_var_accounts_tmout">300</xccdf:set-value>
</xccdf:Profile>
</xccdf:Tailoring>
```
### Kubernetes Query Example
Rule check_content:
```json
{
"resource_type": "image.config.openshift.io",
"resource_name": "cluster",
"yamlpath": ".spec.allowedRegistriesForImport[:].insecure",
"expected_value": "false",
"condition": "not_equals"
}
```
Scanner execution:
```bash
kubectl get image.config.openshift.io cluster \\
-o jsonpath='{.spec.allowedRegistriesForImport[:].insecure}'
```
### Parallel Scanner Execution
```python
scanner_tasks = [
oscap_scanner.scan(oscap_rules, target, variables),
k8s_scanner.scan(k8s_rules, target, variables)
]
results = await asyncio.gather(*scanner_tasks)
```
## Testing
Integration testing requires:
- MongoDB with compliance rules (Issue #96)
- OSCAP installed (`oscap --version`)
- Test SSH target or local system
- Optional: Kubernetes cluster for K8s scanner tests
## Next Steps
After this PR merges:
1. **Issue #5**: ORSA Plugin Architecture (5-7 days)
- Execute remediation content (Ansible, Bash)
- Track remediation status
- Rollback support
2. **Issue #6**: Scan Configuration API (3-4 days)
- UI for benchmark selection
- Variable customization interface
- Tailoring file management
3. **Issue #7**: Frontend Variable Customization UI (5-7 days)
- Framework selection
- Variable override forms
- Real-time scan status
## Related Issues
- Closes: #100
- Requires: #98 (XCCDF generator) - PR #99 pending
- Blocks: #5 (ORSA Plugin Architecture)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
11 tasks
remyluslosius
added a commit
that referenced
this pull request
Oct 15, 2025
…ash Executors
Implements complete ORSA (OpenWatch Remediation and Security Automation) plugin
architecture for automated remediation execution after compliance scans.
## New Components (7 files, ~2,500 lines)
### 1. MongoDB Models (backend/app/models/remediation_models.py - 330 lines)
**Purpose**: Track remediation execution lifecycle and results
**Key Models**:
- RemediationResult: Complete execution record with rollback support
- Tracks status: pending → running → completed/failed/rolled_back
- Stores stdout/stderr, changes made, variables applied
- Audit log with timestamped actions
- Rollback content and execution tracking
- BulkRemediationJob: Batch remediation coordinator
- Progress tracking (total, completed, failed counts)
- Success rate calculation
- Individual remediation ID tracking
- RemediationRequest/BulkRemediationRequest: API request schemas
- RemediationSummary: Aggregated statistics
**Indexes**: remediation_id, rule_id, status, executed_by, scan_id, created_at
### 2. Base Executor Interface (backend/app/services/remediators/base_executor.py - 280 lines)
**Purpose**: Abstract interface for all remediation executors
**Design Pattern**: Strategy pattern for pluggable executors
**Key Features**:
- Abstract methods: execute(), rollback(), validate_content(), supports_target()
- Capability system: DRY_RUN, ROLLBACK, IDEMPOTENT, VARIABLE_SUBSTITUTION, REMOTE_EXECUTION
- Custom exceptions: ExecutorNotAvailableError, ExecutorValidationError, ExecutorExecutionError
- Variable substitution: {{var}} and ${var} patterns
- Change extraction for rollback tracking
- Async context manager support
**ExecutorMetadata**: Version, capabilities, supported targets for discovery
### 3. Ansible Executor (backend/app/services/remediators/ansible_executor.py - 380 lines)
**Purpose**: Execute Ansible playbooks from string content
**Capabilities**:
- ✅ Dry-run (--check mode)
- ✅ Rollback support
- ✅ Idempotent operations
- ✅ Variable substitution (--extra-vars)
- ✅ Remote execution (SSH)
**Features**:
- Dynamic inventory generation (local or SSH targets)
- YAML validation via yaml.safe_load()
- SSH key management (temp files with 0600 permissions)
- Ansible output parsing (PLAY RECAP, changed counts)
- Change extraction from task output
- Timeout support with process cleanup
**Execution Flow**:
1. Validate playbook YAML structure
2. Generate inventory file (local or remote)
3. Write SSH key if provided
4. Build ansible-playbook command with --extra-vars, --check, --private-key
5. Execute with timeout
6. Parse PLAY RECAP for change counts
7. Extract changes for rollback tracking
**Example Command**:
```bash
ansible-playbook playbook.yml -i inventory.ini \
--extra-vars '{"var_tmout": "300"}' \
--check \
--private-key ssh_key \
-e ansible_host_key_checking=False
```
### 4. Bash Executor (backend/app/services/remediators/bash_executor.py - 380 lines)
**Purpose**: Execute bash scripts from string content
**Capabilities**:
- ✅ Variable substitution (export statements)
- ✅ Remote execution (SSH)
- ⚠️ Limited dry-run (syntax check only via bash -n)
- ⚠️ NOT idempotent by default
**Features**:
- Syntax validation: bash -n (noexec mode)
- Variable preparation: Prepends export statements
- Local execution: Direct bash script_file
- Remote execution: SSH with script piped to stdin
- Change extraction: Looks for "Changed:", "Modified:", "Created:" patterns
- Timeout support
**Script Preparation**:
```bash
#!/bin/bash
set -e # Exit on error
# Environment variables
export var_tmout='300'
export var_password_minlen='14'
# Remediation script
[original content]
```
**Remote Execution**:
```bash
ssh -i ssh_key -o StrictHostKeyChecking=no \
root@192.168.1.100 'bash -s' < script.sh
```
### 5. Executor Factory (backend/app/services/remediators/__init__.py - 180 lines)
**Purpose**: Registry and factory for executor instantiation
**Pattern**: Factory pattern with runtime registration
**Registry**:
- ansible: AnsibleExecutor
- bash: BashExecutor
- (Future): terraform, kubernetes, python
**Methods**:
- get_executor(type): Instantiate executor
- register_executor(type, class): Runtime plugin registration
- list_executors(available_only): Discovery
- get_executor_metadata(type): Capabilities, version, targets
- get_all_executor_metadata(): All registered executors
**Example**:
```python
executor = RemediationExecutorFactory.get_executor('ansible')
metadata = RemediationExecutorFactory.get_executor_metadata('ansible')
# {"name": "ansible", "version": "2.14.3", "capabilities": [...]}
```
### 6. Remediation Orchestrator (backend/app/services/remediation_orchestrator_service.py - 420 lines)
**Purpose**: Central coordinator for remediation lifecycle
**Workflow**:
1. Query rule from MongoDB
2. Extract remediation content and type
3. Prepare variables (defaults + overrides)
4. Get executor from factory
5. Execute remediation
6. Track status: PENDING → RUNNING → COMPLETED/FAILED
7. Generate rollback content if successful
8. Store RemediationResult in MongoDB
9. Add audit log entries
**Key Methods**:
- execute_remediation(): Single rule execution
- execute_bulk_remediation(): Batch execution from scan results
- Query failed rules from scan
- Execute each remediation sequentially
- Track job progress (completed/failed counts)
- Calculate success rate
- rollback_remediation(): Execute rollback content
- get_remediation_result(): Query by ID
- list_remediations(): Pagination and filtering
- get_remediation_statistics(): Aggregated stats
**Bulk Remediation Sources**:
1. scan_id: Remediate all failed rules from scan
2. rule_ids: Explicit list of rules
3. rule_filter: Query filter (e.g., {"severity": ["high"]})
**Variable Preparation**:
```python
# Start with rule defaults
if 'xccdf_variables' in rule:
for var_id, var_def in rule['xccdf_variables'].items():
variables[var_id] = var_def['default']
# Apply user overrides
variables.update(overrides)
```
### 7. Remediation API (backend/app/api/v1/endpoints/remediation_api.py - 420 lines)
**Purpose**: REST API for remediation operations
**Endpoints**:
- POST /api/v1/remediation/execute - Execute single remediation
- POST /api/v1/remediation/execute-bulk - Batch remediation
- GET /api/v1/remediation/{id} - Get result
- GET /api/v1/remediation/ - List with filters (status, scan_id, pagination)
- POST /api/v1/remediation/{id}/rollback - Rollback remediation
- DELETE /api/v1/remediation/{id} - Delete result
- GET /api/v1/remediation/statistics/summary - Aggregated stats
- GET /api/v1/remediation/executors/available - List executors
- GET /api/v1/remediation/jobs/{id} - Get bulk job status
**Authorization**:
- Users can only view/execute/rollback their own remediations
- Admins can access all remediations
**Query Parameters**:
- skip/limit: Pagination
- status: Filter by RemediationStatus
- scan_id: Filter by source scan
## API Usage Examples
### Execute Single Remediation
```bash
curl -X POST http://localhost:8000/api/v1/remediation/execute \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"rule_id": "xccdf_com.hanalyx.openwatch_rule_accounts_tmout",
"target": {
"type": "ssh_host",
"identifier": "192.168.1.100",
"credentials": {
"username": "root",
"ssh_key": "-----BEGIN OPENSSH PRIVATE KEY-----\n..."
}
},
"variable_overrides": {
"var_accounts_tmout": "300"
},
"dry_run": false
}'
```
### Bulk Remediation (Failed Rules from Scan)
```bash
curl -X POST http://localhost:8000/api/v1/remediation/execute-bulk \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{
"scan_id": "550e8400-e29b-41d4-a716-446655440000",
"rule_filter": {
"severity": ["high", "critical"]
},
"target": {
"type": "ssh_host",
"identifier": "prod-web-01.example.com",
"credentials": {...}
},
"dry_run": true
}'
```
### Rollback Remediation
```bash
curl -X POST http://localhost:8000/api/v1/remediation/{id}/rollback \
-H "Authorization: Bearer $TOKEN"
```
### List Remediations
```bash
curl "http://localhost:8000/api/v1/remediation/?status=completed&limit=10" \
-H "Authorization: Bearer $TOKEN"
```
### Get Statistics
```bash
curl "http://localhost:8000/api/v1/remediation/statistics/summary?days=30" \
-H "Authorization: Bearer $TOKEN"
# Response:
{
"total": 150,
"completed": 120,
"failed": 20,
"success_rate": 80.0,
"by_executor": {"ansible": 100, "bash": 50}
}
```
### List Available Executors
```bash
curl http://localhost:8000/api/v1/remediation/executors/available \
-H "Authorization: Bearer $TOKEN"
# Response:
[
{
"name": "ansible",
"version": "2.14.3",
"capabilities": ["dry_run", "rollback", "idempotent"],
"available": true
}
]
```
## Remediation Execution Flow
```
API Request
↓
RemediationOrchestrator.execute_remediation()
↓
Query rule from MongoDB
↓
Extract remediation: {type: "ansible", content: "..."}
↓
Prepare variables: defaults + overrides
↓
RemediationExecutorFactory.get_executor(type)
↓
AnsibleExecutor.execute(content, target, variables, dry_run)
↓
1. Validate playbook YAML
2. Generate inventory file
3. Write SSH key (0600 permissions)
4. Build command: ansible-playbook --extra-vars --check --private-key
5. Execute with timeout
6. Parse PLAY RECAP for changes
↓
RemediationExecutionResult: {success, stdout, stderr, changes_made, duration}
↓
Update RemediationResult:
- status: RUNNING → COMPLETED/FAILED
- execution_result: {...}
- rollback_available: true (if changes made)
- rollback_content: "..." (future: auto-generated)
↓
Save to MongoDB
↓
Add audit log entry: "Completed"
↓
Return RemediationResult
```
## Executor Capabilities Matrix
| Executor | Dry-Run | Rollback | Idempotent | Variables | Remote | Version Detection |
|----------|---------|----------|------------|-----------|--------|-------------------|
| Ansible | ✅ Full | ✅ Yes | ✅ Yes | ✅ Yes | ✅ SSH | ansible-playbook --version |
| Bash | ⚠️ Syntax only | ✅ Yes | ❌ No | ✅ Yes | ✅ SSH | bash --version |
| Terraform (future) | ✅ Plan | ✅ Yes | ✅ Yes | ✅ Yes | ✅ Providers | terraform version |
| Kubernetes (future) | ✅ --dry-run | ✅ Yes | ✅ Yes | ✅ Yes | ✅ kubectl | kubectl version |
## Security Considerations
1. **SSH Key Storage**:
- Temporary files with 0600 permissions
- Deleted after execution
- TODO: Encrypt in MongoDB (currently plaintext in credentials dict)
2. **Script Execution**:
- Bash scripts run with 'set -e' (exit on error)
- Ansible uses --check for dry-run validation
- Timeout enforcement prevents runaway processes
3. **Authorization**:
- Users can only access their own remediations
- Admins can access all
- Rollback requires original execution ownership
4. **Audit Trail**:
- All status changes logged with timestamps
- Username tracking: executed_by
- Complete stdout/stderr capture
## Dependencies
**Python Packages** (add to requirements.txt):
- ansible-core>=2.14.0 (for Ansible executor)
- paramiko>=3.0.0 (for SSH in Bash executor)
- pyyaml>=6.0 (for Ansible playbook parsing)
**System Tools**:
- ansible-playbook (Ansible executor)
- bash (Bash executor)
- ssh (remote execution)
## Known Limitations
1. **Rollback Generation**: Not yet implemented
- Currently returns None in _generate_rollback_content()
- Future: Parse changes_made and generate inverse operations
2. **Bash Idempotency**: Scripts are NOT idempotent by default
- Users must write idempotent scripts manually
- Consider adding idempotency wrappers (check-before-change)
3. **Ansible Vault**: Not yet implemented
- No support for encrypted playbooks or variables
- Future: Add --vault-password-file support
4. **Parallel Bulk Execution**: Sequential only
- execute_bulk_remediation() runs remediations one-by-one
- Future: Use asyncio.gather() for parallel execution
5. **Credential Encryption**: SSH keys stored plaintext in MongoDB
- TODO: Integrate with Fernet encryption (like scan credentials)
## Testing Strategy
**Unit Tests Needed**:
- Executor validation methods
- Variable substitution
- Change extraction from output
- Error handling (timeouts, invalid content)
**Integration Tests Needed**:
- Ansible playbook execution against test VM
- Bash script execution (local and remote)
- Rollback functionality
- Bulk remediation workflow
**E2E Tests**:
1. Scan → Identify Failed Rules
2. Remediate (dry-run=true) → Verify no changes
3. Remediate (dry-run=false) → Apply changes
4. Re-scan → Verify rules now pass
5. Rollback → Restore original state
6. Re-scan → Verify rules fail again
## Future Enhancements
1. **Additional Executors**:
- TerraformExecutor: Infrastructure remediation
- KubernetesExecutor: Manifest application
- PythonExecutor: Custom Python scripts
2. **Intelligent Rollback**:
- Parse execution output for changes
- Generate inverse operations automatically
- Store pre-remediation state snapshots
3. **Approval Workflow**:
- Require manual approval for production systems
- Multi-stage approval (dev → staging → prod)
4. **Parallel Execution**:
- Bulk remediation with asyncio.gather()
- Dependency resolution for ordered execution
5. **Remediation Templates**:
- Pre-built remediation content library
- Template variables with validation
## Phase 1 Status
✅ Completed (5/7 tasks):
1. ✅ Enhanced ComplianceRule Model (PR #95 - merged)
2. ✅ Enhanced SCAP Converter (PR #97 - pending)
3. ✅ XCCDF Generator (PR #99 - pending)
4. ✅ Scan Service (PR #101 - pending)
5. ✅ **ORSA Remediation Engine (this commit)**
🚧 Remaining (2/7 tasks):
6. ⏳ Scan Configuration API (3-4 days)
7. ⏳ Frontend Variable Customization UI (5-7 days)
## Related Issues
- Implements: #102
- Depends on: #96 (PR #97 - remediation field)
- Blocks: #6 (Scan Configuration API)
Co-Authored-By: Claude <noreply@anthropic.com>
20 tasks
remyluslosius
added a commit
that referenced
this pull request
Oct 15, 2025
…very & Template Management
Implements complete scan configuration API for framework selection, variable
management, and template-based scan configurations.
New Components (4 files, ~1,800 lines)
1. Scan Configuration Models (backend/app/models/scan_config_models.py - 280 lines)
Purpose: MongoDB models and API schemas for templates and framework metadata
Key Models:
- ScanTemplate: Saved scan configuration with framework, variables, filters, sharing
- VariableDefinition: XCCDF variable with type and constraints
- FrameworkMetadata: Framework discovery with counts and versions
- API Schemas: Request/response models
2. Framework Metadata Service (backend/app/services/framework_metadata_service.py - 420 lines)
Purpose: Discover frameworks and validate variable values
Key Methods:
- list_frameworks(): Aggregate framework metadata
- get_framework_details(): Complete framework/version info
- get_variables(): Extract variables from rules
- validate_variable_value(): Constraint validation (type, range, choices, regex)
- validate_variables(): Batch validation
3. Scan Template Service (backend/app/services/scan_template_service.py - 380 lines)
Purpose: CRUD operations for scan templates
Key Methods:
- create_template(), list_templates(), update_template(), delete_template()
- apply_template(): Generate scan configuration
- set_as_default(), clone_template()
- share_template()/unshare_template(): Access control
4. Scan Configuration API (backend/app/api/v1/endpoints/scan_config_api.py - 720 lines)
Purpose: REST API with 14 endpoints
Framework Discovery:
- GET /frameworks
- GET /frameworks/{framework}/{version}
- GET /frameworks/{framework}/{version}/variables
- POST /frameworks/{framework}/{version}/validate
Template Management:
- POST /templates
- GET /templates
- GET /templates/{id}
- PUT /templates/{id}
- DELETE /templates/{id}
- POST /templates/{id}/apply
- POST /templates/{id}/clone
- POST /templates/{id}/set-default
- GET /statistics
Phase 1 Status: 6/7 tasks completed (86%)
Related Issues:
- Implements: #104
- Depends on: #98 (PR #99), #100 (PR #101)
- Blocks: #7 (Frontend UI)
Co-Authored-By: Claude <noreply@anthropic.com>
remyluslosius
added a commit
that referenced
this pull request
Oct 15, 2025
…plate Management Merged after successful syntax validation and CI checks
10 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps actions/upload-artifact from 3 to 4.
Release notes
Sourced from actions/upload-artifact's releases.
... (truncated)
Commits
ea165f8Merge pull request #685 from salmanmkc/salmanmkc/3-new-upload-artifacts-release0839620Prepare for new release of actions/upload-artifact with new toolkit cache ver...4cec3d8Merge pull request #673 from actions/yacaovsnc/artifact_2.2.2e9fad96license cache update for artifactb26fd06Update to use artifact 2.2.2 package65c4c4aMerge pull request #662 from actions/yacaovsnc/add_variable_for_concurrency_a...0207619move files back to satisfy licensed ci1ecca81licensed cache updates9742269Expose env vars to controll concurrency and timeout6f51ac0Merge pull request #656 from bdehamer/bdehamer/artifact-digestDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)