## Summary Part of the [Implement Remediation Profiles as extension of Security Scan Profiles](https://gitlab.com/gitlab-org/gitlab/-/work_items/603085) issue. ## Goal Auto-remediation behavior is governed by the attached remediation profile's configuration. Projects without a profile keep existing hardcoded behavior. ## Backend changes **`ee/app/services/dependency_management/security_update/scheduler_service.rb`**: - Read config from `project.post_processing_profile_for(:dependency_scanning_post_processing)` - Check `profile.configuration.dig('auto_remediation', 'enabled')` before proceeding - Fall back to existing constants (`MAX_OPEN_MERGE_REQUEST_LIMIT`, `SUPPORTED_PACKAGE_MANAGERS`, `SORTED_SEVERITY_LEVELS`) when no profile attached - Use `profile.configuration.dig('auto_remediation', 'max_open_merge_requests')`, `...'enabled_ecosystems'`, `...'severity_levels'` **`ee/app/workers/dependency_management/security_update/scheduler_worker.rb`**: - Add alternative enablement: allow auto-remediation when a remediation profile is attached, even without the `dependency_management_auto_remediation` feature flag ## Verification - Attach profile with `auto_remediation.max_open_merge_requests: 5` — scheduler respects 5 limit - Attach profile with `auto_remediation.enabled_ecosystems: ["bundler"]` — only bundler remediated - Attach profile with `auto_remediation.enabled: false` — scheduler skips auto-remediation - No profile attached — existing hardcoded behavior unchanged