The following discussion from !228920 should be addressed: - [ ] @Andyschoenen started a [discussion](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/228920#note_3228656414): (+1 comment) > **Question:** I went through the steps in the description and the merge request was blocked like expected. But when I remove the security attribute from the project, the MR was still blocked. Is this expected? #### Where Security Attributes Are Removed from a Project The removal happens in `ee/app/services/security/attributes/update_project_attributes_service.rb`. The `apply_changes` method deletes the `ProjectToSecurityAttribute` join records inside a transaction: ee/app/services/security/attributes/update_project_attributes_service.rb ```ruby def apply_changes Security::ProjectToSecurityAttribute.transaction do if associations_to_destroy.present? Security::ProjectToSecurityAttribute.id_in(associations_to_destroy.map(&:id)).delete_all end Security::ProjectToSecurityAttribute.bulk_insert!(associations_to_create, skip_duplicates: true) end end ``` After the deletion, `create_audit_events` fires a `security_attribute_detached_from_project` audit event, but **nothing triggers a re-evaluation of security policies**. This is the root cause of [#596003](https://gitlab.com/gitlab-org/gitlab/-/work_items/596003). The removal can be triggered from two places: * **GraphQL mutation** `securityAttributeProjectUpdate` (via `Mutations::Security::Attributes::ProjectUpdate`) * **Frontend** in `ee/app/assets/javascripts/security_configuration/security_attributes/components/project_attributes_list.vue` calling `ProjectSecurityAttributesUpdateMutation` #### Why Policies Are Not Re-evaluated The `PolicyScopeChecker` (`ee/lib/security/security_orchestration_policies/policy_scope_checker.rb`) checks `business_impact` scope at evaluation time, but there is no event published when attributes change to trigger re-evaluation. Compare this to how **compliance frameworks** work: when a framework is removed, `Projects::ComplianceFrameworkChangedEvent` is published, which `SyncPolicyEventWorker` subscribes to and calls `SyncProjectPolicyWorker` for each affected policy. The `business_impact` scope has no equivalent event/subscriber chain. --- #### Plan to Re-trigger Security Policy Evaluation The approach mirrors the existing compliance framework pattern: **1. Define a new event** (`ee/app/events/projects/security_attribute_changed_event.rb`) ```ruby module Projects class SecurityAttributeChangedEvent < ::Gitlab::EventStore::Event EVENT_TYPES = { added: 'added', removed: 'removed' }.freeze def schema { 'type' => 'object', 'properties' => { 'project_id' => { 'type' => 'integer' }, 'security_attribute_id' => { 'type' => 'integer' }, 'event_type' => { 'type' => 'string', 'enum' => EVENT_TYPES.values } }, 'required' => %w[project_id security_attribute_id event_type] } end end end ``` **2. Publish the event from `UpdateProjectAttributesService`** after `apply_changes`: `# in create_audit_events or a new publish_events method ```ruby def publish_events associations_to_destroy.each do |assoc| ::Gitlab::EventStore.publish( Projects::SecurityAttributeChangedEvent.new(data: { project_id: project.id, security_attribute_id: assoc.security_attribute_id, event_type: Projects::SecurityAttributeChangedEvent::EVENT_TYPES[:removed] }) ) end # similarly for associations_to_create with :added end ``` **3. Subscribe in `SyncPolicyEventWorker`** (`ee/app/workers/security/sync_policy_event_worker.rb`): Add `Projects::SecurityAttributeChangedEvent` to the `handle_event` case and implement a handler: ```ruby when ::Projects::SecurityAttributeChangedEvent sync_rules_for_security_attribute_changed_event(event) ``` ```ruby def sync_rules_for_security_attribute_changed_event(event) project = Project.find_by_id(event.data[:project_id]) return unless project return unless project.licensed_feature_available?(:security_orchestration_policies) # Find all policies scoped to business_impact that apply to this project project.all_security_orchestration_policy_configuration_ids.each do |config_id| Security::Policy .for_policy_configuration_ids([config_id]) .undeleted .select { |p| p.scope.dig('business_impact').present? } .each { |p| sync_project_policy(project, p.id, event) } end end ``` **4. Handle the event in `SyncPolicyEventService`** (`ee/app/services/security/security_orchestration_policies/sync_policy_event_service.rb`): ```ruby when Projects::SecurityAttributeChangedEvent sync_policy_for_security_attribute(event) ``` ```ruby def sync_policy_for_security_attribute(event) # Re-evaluate scope: link or unlink based on current attribute state if scope_applicable? link_policy else unlink_policy end end ``` This is similar to what we did for `sync_policy_for_compliance_framework` works for compliance framework changes in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/173259 **5. Register the subscription** in the EventStore initializer (wherever `SyncPolicyEventWorker` subscriptions are declared), adding `Projects::SecurityAttributeChangedEvent`. --- #### Summary of Files to Change | File | Change | |------|--------| | `ee/app/events/projects/security_attribute_changed_event.rb` | **New** - define the event | | `ee/app/services/security/attributes/update_project_attributes_service.rb` | Publish the event after `apply_changes` | | `ee/app/workers/security/sync_policy_event_worker.rb` | Subscribe and handle the new event | | `ee/app/services/security/security_orchestration_policies/sync_policy_event_service.rb` | Add `sync_policy_for_security_attribute` case | | EventStore subscriptions initializer | Register `SyncPolicyEventWorker` for the new event | This ensures that when a `business_impact` attribute is removed from a project, all policies scoped to that attribute are re-evaluated. ## How to set up and validate locally 1. Create a new group 2. Create a new project 3. Add a `.gitlab-ci.yml` file to the project with the content: ```yaml include: - template: Jobs/SAST.gitlab-ci.yml ``` 4. Add an empty `test.rb` file 5. Go to Secure > Security Configuration in the project 6. Select Security attributes 7. Click on Edit project security attributes 8. Select `Mission Critical` 9. Go back to the group created on step 1 10. Go to Secure > Policies 11. Click on New policy 12. Select Merge request approval policy 13. Create a policy to block new vulnerabilities on `Mission Critical` projects 14. Get the `security_attribute` id ```ruby category = Security::Category.where(template_type: "business_impact").where(namespace: Group.last) security_attribute_id = Security::Attribute.where(security_category: category).where(name: "Mission Critical").first ``` 15. Create a policy like ```yaml approval_policy: - name: Test description: '' enabled: true rules: - type: scan_finding branches: [] vulnerabilities_allowed: 0 severity_levels: [] vulnerability_states: [] scanners: - type: sast vulnerabilities_allowed: 0 severity_levels: - critical - high vulnerability_states: - new_needs_triage vulnerability_attributes: false_positive: false policy_scope: business_impact: including: - id: <security_attribute_id> actions: - type: require_approval approvals_required: 1 role_approvers: - developer ``` 16. Click on Create new project with the new policy 17. Merge the MR to add the policy 18. Go back to the project created in step 2 19. Create a MR adding the file `vuln.rb` with the content ```ruby class RunScript def run_script system("cat #{params[:path]}") end end ``` 20. Verify the MR is blocked 21. Go to Secure > Security Configuration 22. Select Security attributes 23. Click on Remove attribute 24. Verify the MR does not require approval anymore, and the bot comment was updated 25. Repeat the steps 5 to 8 to add the security attribute again 26. Verify the MR is blocked again, and the bot comment was updated