Broadcast filtering can improve airtime while breaking address assignment or cross-AP discovery if applied blindly.
\nUbiquiti’s broadcast-management guide distinguishes multicast-to-unicast conversion from SSID multicast and broadcast control. Conversion can help smaller networks but can increase airtime when many clients subscribe. The SSID control instead restricts traffic to approved MAC addresses. Ubiquiti warns that it blocks cross-AP device discovery and that the DHCP server’s MAC address must be allowed for clients to obtain addresses. Device isolation is another separate measure that prevents direct client communication, including discovery and casting, rather than simply changing how multicast is transmitted.
\nSource: Ubiquiti — Broadcast traffic management.
\nThis concerns UniFi Network wireless broadcast and multicast settings. Model and switch support varies for other isolation features, and a device-discovery requirement must be assessed for the actual network.
\nDSE recommends recording which discovery, casting, printing, and address-assignment workflows must survive before filtering traffic. Measure the symptom and choose the specific control that addresses it. Identify the actual DHCP server path and authorized MAC entries rather than copying values from an example. Pilot one SSID or test area with representative clients and APs. Keep a clear rollback and avoid stacking conversion, filtering, and isolation changes at once, since their different effects otherwise become difficult to diagnose.
\nTest a fresh DHCP lease, ordinary application connectivity, and required discovery across two APs after an approved pilot change. Compare airtime under representative load and review both subscribed and nonsubscribed clients. Confirm the chosen setting solves the measured problem without silently removing a required discovery workflow.
\nUbiquiti — Broadcast traffic management. Reviewed October 15, 2026.
", "content_text": "Broadcast filtering can improve airtime while breaking address assignment or cross-AP discovery if applied blindly.\nSource facts\nUbiquiti’s broadcast-management guide distinguishes multicast-to-unicast conversion from SSID multicast and broadcast control. Conversion can help smaller networks but can increase airtime when many clients subscribe. The SSID control instead restricts traffic to approved MAC addresses. Ubiquiti warns that it blocks cross-AP device discovery and that the DHCP server’s MAC address must be allowed for clients to obtain addresses. Device isolation is another separate measure that prevents direct client communication, including discovery and casting, rather than simply changing how multicast is transmitted.\nSource: Ubiquiti — Broadcast traffic management.\nApplicability\nThis concerns UniFi Network wireless broadcast and multicast settings. Model and switch support varies for other isolation features, and a device-discovery requirement must be assessed for the actual network.\nDSE recommendation\nDSE recommends recording which discovery, casting, printing, and address-assignment workflows must survive before filtering traffic. Measure the symptom and choose the specific control that addresses it. Identify the actual DHCP server path and authorized MAC entries rather than copying values from an example. Pilot one SSID or test area with representative clients and APs. Keep a clear rollback and avoid stacking conversion, filtering, and isolation changes at once, since their different effects otherwise become difficult to diagnose.\nVerification\nTest a fresh DHCP lease, ordinary application connectivity, and required discovery across two APs after an approved pilot change. Compare airtime under representative load and review both subscribed and nonsubscribed clients. Confirm the chosen setting solves the measured problem without silently removing a required discovery workflow.\nOfficial reference\nUbiquiti — Broadcast traffic management. Reviewed October 15, 2026.", "content_markdown": "Broadcast filtering can improve airtime while breaking address assignment or cross-AP discovery if applied blindly.\n\n## Source facts\n\nUbiquiti’s broadcast-management guide distinguishes multicast-to-unicast conversion from SSID multicast and broadcast control. Conversion can help smaller networks but can increase airtime when many clients subscribe. The SSID control instead restricts traffic to approved MAC addresses. Ubiquiti warns that it blocks cross-AP device discovery and that the DHCP server’s MAC address must be allowed for clients to obtain addresses. Device isolation is another separate measure that prevents direct client communication, including discovery and casting, rather than simply changing how multicast is transmitted.\n\nSource: [Ubiquiti — Broadcast traffic management](https://help.ui.com/hc/en-us/articles/27384925962647-Managing-Broadcast-Traffic-with-UniFi).\n\n## Applicability\n\nThis concerns UniFi Network wireless broadcast and multicast settings. Model and switch support varies for other isolation features, and a device-discovery requirement must be assessed for the actual network.\n\n## DSE recommendation\n\nDSE recommends recording which discovery, casting, printing, and address-assignment workflows must survive before filtering traffic. Measure the symptom and choose the specific control that addresses it. Identify the actual DHCP server path and authorized MAC entries rather than copying values from an example. Pilot one SSID or test area with representative clients and APs. Keep a clear rollback and avoid stacking conversion, filtering, and isolation changes at once, since their different effects otherwise become difficult to diagnose.\n\n## Verification\n\nTest a fresh DHCP lease, ordinary application connectivity, and required discovery across two APs after an approved pilot change. Compare airtime under representative load and review both subscribed and nonsubscribed clients. Confirm the chosen setting solves the measured problem without silently removing a required discovery workflow.\n\n## Official reference\n\n[Ubiquiti — Broadcast traffic management](https://help.ui.com/hc/en-us/articles/27384925962647-Managing-Broadcast-Traffic-with-UniFi). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/google-workspace-recipient-map-original-delivery-header/", "slug": "google-workspace-recipient-map-original-delivery-header", "url": "https://update.dsesecurity.com/updates/google-workspace-recipient-map-original-delivery-header/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/google-workspace-recipient-map-original-delivery-header.md", "json": "https://update.dsesecurity.com/api/v1/posts/google-workspace-recipient-map-original-delivery-header/" }, "title": "Choose whether a Google recipient map redirects or also delivers the original message", "summary": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "microsoft-365-identity", "name": "Microsoft 365 & Identity", "url": "https://update.dsesecurity.com/topic/microsoft-365-identity/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:59+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 277, "potentially_affected": "This applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.", "dse_recommendation": "DSE recommends recording the business purpose and delivery outcome before creating an address map.", "primary_source": { "name": "Google — Recipient address maps", "url": "https://knowledge.workspace.google.com/admin/gmail/advanced/redirect-or-forward-gmail-messages-to-another-user?hl=en", "published_on": null, "authority": "knowledge.workspace.google.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.
\nGoogle Workspace recipient address maps can redirect incoming mail or forward it to additional recipients. The Also route to original destination option preserves delivery to the original mailbox; without it, a redirect can send the message only to the mapped destination. The rule can cover all incoming messages, including internal mail, or only external incoming messages. An optional X-Gm-Original-To header preserves the original recipient for header-based processing and diagnostics. Google documents this administrator mapping under Gmail Routing, distinct from Default routing and user-managed automatic forwarding.
\nSource: Google — Recipient address maps.
\nThis applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.
\nDSE recommends recording the business purpose and delivery outcome before creating an address map. For an absence, decide whether both mailboxes should receive new messages; for a replacement workflow, confirm who owns the destination and how long the map should remain. Review internal and external message scope separately. Preserve original-recipient information when approved downstream processing needs it. Check existing mappings for loops or duplicate delivery paths and assign a removal or review date so temporary forwarding does not become an unowned data-sharing arrangement.
\nSend approved synthetic messages from both internal and external test senders. Confirm delivery at every intended mailbox and inspect the optional original-recipient header where enabled. Verify that no unintended duplicate or redirect loop occurs and distinguish new-message routing from access to historical mailbox data.
\nGoogle — Recipient address maps. Reviewed October 15, 2026.
", "content_text": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.\nSource facts\nGoogle Workspace recipient address maps can redirect incoming mail or forward it to additional recipients. The Also route to original destination option preserves delivery to the original mailbox; without it, a redirect can send the message only to the mapped destination. The rule can cover all incoming messages, including internal mail, or only external incoming messages. An optional X-Gm-Original-To header preserves the original recipient for header-based processing and diagnostics. Google documents this administrator mapping under Gmail Routing, distinct from Default routing and user-managed automatic forwarding.\nSource: Google — Recipient address maps.\nApplicability\nThis applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.\nDSE recommendation\nDSE recommends recording the business purpose and delivery outcome before creating an address map. For an absence, decide whether both mailboxes should receive new messages; for a replacement workflow, confirm who owns the destination and how long the map should remain. Review internal and external message scope separately. Preserve original-recipient information when approved downstream processing needs it. Check existing mappings for loops or duplicate delivery paths and assign a removal or review date so temporary forwarding does not become an unowned data-sharing arrangement.\nVerification\nSend approved synthetic messages from both internal and external test senders. Confirm delivery at every intended mailbox and inspect the optional original-recipient header where enabled. Verify that no unintended duplicate or redirect loop occurs and distinguish new-message routing from access to historical mailbox data.\nOfficial reference\nGoogle — Recipient address maps. Reviewed October 15, 2026.", "content_markdown": "The original-delivery checkbox changes whether the first mailbox still receives mapped messages.\n\n## Source facts\n\nGoogle Workspace recipient address maps can redirect incoming mail or forward it to additional recipients. The Also route to original destination option preserves delivery to the original mailbox; without it, a redirect can send the message only to the mapped destination. The rule can cover all incoming messages, including internal mail, or only external incoming messages. An optional X-Gm-Original-To header preserves the original recipient for header-based processing and diagnostics. Google documents this administrator mapping under Gmail Routing, distinct from Default routing and user-managed automatic forwarding.\n\nSource: [Google — Recipient address maps](https://knowledge.workspace.google.com/admin/gmail/advanced/redirect-or-forward-gmail-messages-to-another-user?hl=en).\n\n## Applicability\n\nThis applies to Google Workspace administrator recipient address maps. It does not grant access to existing mailbox contents, establish a delegate relationship, or determine whether the mapped recipient may send as the original user.\n\n## DSE recommendation\n\nDSE recommends recording the business purpose and delivery outcome before creating an address map. For an absence, decide whether both mailboxes should receive new messages; for a replacement workflow, confirm who owns the destination and how long the map should remain. Review internal and external message scope separately. Preserve original-recipient information when approved downstream processing needs it. Check existing mappings for loops or duplicate delivery paths and assign a removal or review date so temporary forwarding does not become an unowned data-sharing arrangement.\n\n## Verification\n\nSend approved synthetic messages from both internal and external test senders. Confirm delivery at every intended mailbox and inspect the optional original-recipient header where enabled. Verify that no unintended duplicate or redirect loop occurs and distinguish new-message routing from access to historical mailbox data.\n\n## Official reference\n\n[Google — Recipient address maps](https://knowledge.workspace.google.com/admin/gmail/advanced/redirect-or-forward-gmail-messages-to-another-user?hl=en). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-directory-connector-shared-config-scheduling/", "slug": "bitwarden-directory-connector-shared-config-scheduling", "url": "https://update.dsesecurity.com/updates/bitwarden-directory-connector-shared-config-scheduling/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-directory-connector-shared-config-scheduling.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-directory-connector-shared-config-scheduling/" }, "title": "Keep Bitwarden Directory Connector’s desktop and scheduled CLI runs from competing", "summary": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:52+00:00", "modified_at": "2026-10-15T13:36:18+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 271, "potentially_affected": "This applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.", "dse_recommendation": "DSE recommends naming one synchronization host and one operational owner.", "primary_source": { "name": "Bitwarden — Directory Connector", "url": "https://bitwarden.com/help/directory-sync/", "published_on": null, "authority": "bitwarden.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.
\nBitwarden Directory Connector pulls users, groups, and associations from a supported source directory. It can run on demand or at a configured interval and can be configured to remove disabled users from the organization without deleting their accounts. The desktop app and CLI share their database and configuration, and Bitwarden does not recommend using them simultaneously on one machine. Its documented approach is to configure and test with the desktop app, then use the CLI to schedule production synchronization.
\nSource: Bitwarden — Directory Connector.
\nThis applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.
\nDSE recommends naming one synchronization host and one operational owner. Complete a reviewed configuration in the desktop app, record the intended source and scope, then document how the scheduled CLI obtains that same configuration. Pause the scheduled task while making controlled desktop changes rather than running competing sessions. Review removal behavior before enabling automatic production runs, and maintain a protected change record for configuration and credential updates. Monitor completion and failures so a silent stalled task does not leave identity changes unapplied.
\nUse test users and groups to compare a desktop run with the intended scheduled CLI run, one at a time. Confirm the configured source scope and handling of a disabled test user. Verify that the schedule reports success or failure and that an administrator knows how to pause it during maintenance.
\nBitwarden — Directory Connector. Reviewed October 15, 2026.
", "content_text": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.\nSource facts\nBitwarden Directory Connector pulls users, groups, and associations from a supported source directory. It can run on demand or at a configured interval and can be configured to remove disabled users from the organization without deleting their accounts. The desktop app and CLI share their database and configuration, and Bitwarden does not recommend using them simultaneously on one machine. Its documented approach is to configure and test with the desktop app, then use the CLI to schedule production synchronization.\nSource: Bitwarden — Directory Connector.\nApplicability\nThis applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.\nDSE recommendation\nDSE recommends naming one synchronization host and one operational owner. Complete a reviewed configuration in the desktop app, record the intended source and scope, then document how the scheduled CLI obtains that same configuration. Pause the scheduled task while making controlled desktop changes rather than running competing sessions. Review removal behavior before enabling automatic production runs, and maintain a protected change record for configuration and credential updates. Monitor completion and failures so a silent stalled task does not leave identity changes unapplied.\nVerification\nUse test users and groups to compare a desktop run with the intended scheduled CLI run, one at a time. Confirm the configured source scope and handling of a disabled test user. Verify that the schedule reports success or failure and that an administrator knows how to pause it during maintenance.\nOfficial reference\nBitwarden — Directory Connector. Reviewed October 15, 2026.", "content_markdown": "The desktop app and CLI share local configuration, so treat them as one synchronization workflow.\n\n## Source facts\n\nBitwarden Directory Connector pulls users, groups, and associations from a supported source directory. It can run on demand or at a configured interval and can be configured to remove disabled users from the organization without deleting their accounts. The desktop app and CLI share their database and configuration, and Bitwarden does not recommend using them simultaneously on one machine. Its documented approach is to configure and test with the desktop app, then use the CLI to schedule production synchronization.\n\nSource: [Bitwarden — Directory Connector](https://bitwarden.com/help/directory-sync/).\n\n## Applicability\n\nThis applies to Bitwarden Directory Connector, not SCIM or SSO authentication. A scheduled process still needs access to the chosen directory and the organization’s provisioning credentials.\n\n## DSE recommendation\n\nDSE recommends naming one synchronization host and one operational owner. Complete a reviewed configuration in the desktop app, record the intended source and scope, then document how the scheduled CLI obtains that same configuration. Pause the scheduled task while making controlled desktop changes rather than running competing sessions. Review removal behavior before enabling automatic production runs, and maintain a protected change record for configuration and credential updates. Monitor completion and failures so a silent stalled task does not leave identity changes unapplied.\n\n## Verification\n\nUse test users and groups to compare a desktop run with the intended scheduled CLI run, one at a time. Confirm the configured source scope and handling of a disabled test user. Verify that the schedule reports success or failure and that an administrator knows how to pause it during maintenance.\n\n## Official reference\n\n[Bitwarden — Directory Connector](https://bitwarden.com/help/directory-sync/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-scim-staged-users-invitation-policy-boundary/", "slug": "bitwarden-scim-staged-users-invitation-policy-boundary", "url": "https://update.dsesecurity.com/updates/bitwarden-scim-staged-users-invitation-policy-boundary/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-scim-staged-users-invitation-policy-boundary.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-scim-staged-users-invitation-policy-boundary/" }, "title": "Distinguish staged Bitwarden SCIM records from invited organization members", "summary": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:51+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "This concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.", "dse_recommendation": "DSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access.", "primary_source": { "name": "Bitwarden — About SCIM", "url": "https://bitwarden.com/help/about-scim/", "published_on": null, "authority": "bitwarden.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.
\nBitwarden SCIM can provision and deprovision organization members and groups from an identity provider using a SCIM endpoint and API key. By default, newly provisioned users enter Staged status rather than receiving an immediate invitation. The Automatically send email invitations setting changes that behavior. Staged users receive no invitation email, do not occupy a license seat, and are not subject to organization policies. The documentation also warns administrators to turn off Directory Connector before enabling SCIM when migrating from that provisioning method.
\nSource: Bitwarden — About SCIM.
\nThis concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.
\nDSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access. Decide whether automatic invitations fit the organization’s joiner process before enabling them. Give helpdesk staff a status-based troubleshooting guide so they do not repeatedly recreate a user whose record is simply staged. During a migration, designate one provisioning authority and retire the previous synchronization job deliberately. Keep the SCIM key in approved secret storage and record its operational owner.
\nProvision a test user with automatic invitations disabled and confirm the staged state and lack of invitation. Then exercise the approved invitation path and check the final collection access. Review the old connector schedule during a SCIM migration to verify that competing synchronization is no longer running.
\nBitwarden — About SCIM. Reviewed October 15, 2026.
", "content_text": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.\nSource facts\nBitwarden SCIM can provision and deprovision organization members and groups from an identity provider using a SCIM endpoint and API key. By default, newly provisioned users enter Staged status rather than receiving an immediate invitation. The Automatically send email invitations setting changes that behavior. Staged users receive no invitation email, do not occupy a license seat, and are not subject to organization policies. The documentation also warns administrators to turn off Directory Connector before enabling SCIM when migrating from that provisioning method.\nSource: Bitwarden — About SCIM.\nApplicability\nThis concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.\nDSE recommendation\nDSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access. Decide whether automatic invitations fit the organization’s joiner process before enabling them. Give helpdesk staff a status-based troubleshooting guide so they do not repeatedly recreate a user whose record is simply staged. During a migration, designate one provisioning authority and retire the previous synchronization job deliberately. Keep the SCIM key in approved secret storage and record its operational owner.\nVerification\nProvision a test user with automatic invitations disabled and confirm the staged state and lack of invitation. Then exercise the approved invitation path and check the final collection access. Review the old connector schedule during a SCIM migration to verify that competing synchronization is no longer running.\nOfficial reference\nBitwarden — About SCIM. Reviewed October 15, 2026.", "content_markdown": "A synchronized staged record does not yet receive an invitation, occupy a seat, or inherit policies.\n\n## Source facts\n\nBitwarden SCIM can provision and deprovision organization members and groups from an identity provider using a SCIM endpoint and API key. By default, newly provisioned users enter Staged status rather than receiving an immediate invitation. The Automatically send email invitations setting changes that behavior. Staged users receive no invitation email, do not occupy a license seat, and are not subject to organization policies. The documentation also warns administrators to turn off Directory Connector before enabling SCIM when migrating from that provisioning method.\n\nSource: [Bitwarden — About SCIM](https://bitwarden.com/help/about-scim/).\n\n## Applicability\n\nThis concerns Bitwarden SCIM provisioning and invitation state on supported organization plans. Provisioning a record is separate from authentication, vault decryption, and assignment of access to collection data.\n\n## DSE recommendation\n\nDSE recommends tracking the onboarding sequence from source-directory assignment through staged record, invitation, acceptance, confirmation, and intended collection access. Decide whether automatic invitations fit the organization’s joiner process before enabling them. Give helpdesk staff a status-based troubleshooting guide so they do not repeatedly recreate a user whose record is simply staged. During a migration, designate one provisioning authority and retire the previous synchronization job deliberately. Keep the SCIM key in approved secret storage and record its operational owner.\n\n## Verification\n\nProvision a test user with automatic invitations disabled and confirm the staged state and lack of invitation. Then exercise the approved invitation path and check the final collection access. Review the old connector schedule during a SCIM migration to verify that competing synchronization is no longer running.\n\n## Official reference\n\n[Bitwarden — About SCIM](https://bitwarden.com/help/about-scim/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-passwordless-member-removal-account-transition/", "slug": "bitwarden-passwordless-member-removal-account-transition", "url": "https://update.dsesecurity.com/updates/bitwarden-passwordless-member-removal-account-transition/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-passwordless-member-removal-account-transition.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-passwordless-member-removal-account-transition/" }, "title": "Plan the Bitwarden account transition before removing a member with no master password", "summary": "A passwordless member can lose access to the entire account unless the documented transition is completed first.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:50+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 278, "potentially_affected": "This applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.", "dse_recommendation": "DSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure.", "primary_source": { "name": "Bitwarden — Onboarding and succession", "url": "https://bitwarden.com/help/onboarding-and-succession/", "published_on": null, "authority": "bitwarden.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A passwordless member can lose access to the entire account unless the documented transition is completed first.
\nBitwarden’s succession guide describes a specific removal risk for members who have no master password because they use SSO with trusted devices. Removing such a member eliminates account access unless account recovery first assigns a master password and the member signs in with that password at least once before removal. Without those steps, the guide says the removed user cannot simply rejoin and must delete the account and receive a new invitation. Revoking organization access also locks out the account until that access is restored.
\nSource: Bitwarden — Onboarding and succession.
\nThis applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.
\nDSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure. Decide with the data owner whether the person is meant to retain an individual account and what data may remain there. If that transition is approved, follow the documented recovery and first-login sequence before removal, using protected credential handling. Keep the timing separate from any immediate security revocation requirement. Do not assume that sending another invitation will repair an account whose required transition was skipped.
\nRehearse the approved sequence with a synthetic passwordless test account. Confirm the assigned master password works through an actual sign-in before removing the test membership. Verify the intended post-removal account behavior and retained organization ownership, then document the outcome without copying credentials or real vault data.
\nBitwarden — Onboarding and succession. Reviewed October 15, 2026.
", "content_text": "A passwordless member can lose access to the entire account unless the documented transition is completed first.\nSource facts\nBitwarden’s succession guide describes a specific removal risk for members who have no master password because they use SSO with trusted devices. Removing such a member eliminates account access unless account recovery first assigns a master password and the member signs in with that password at least once before removal. Without those steps, the guide says the removed user cannot simply rejoin and must delete the account and receive a new invitation. Revoking organization access also locks out the account until that access is restored.\nSource: Bitwarden — Onboarding and succession.\nApplicability\nThis applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.\nDSE recommendation\nDSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure. Decide with the data owner whether the person is meant to retain an individual account and what data may remain there. If that transition is approved, follow the documented recovery and first-login sequence before removal, using protected credential handling. Keep the timing separate from any immediate security revocation requirement. Do not assume that sending another invitation will repair an account whose required transition was skipped.\nVerification\nRehearse the approved sequence with a synthetic passwordless test account. Confirm the assigned master password works through an actual sign-in before removing the test membership. Verify the intended post-removal account behavior and retained organization ownership, then document the outcome without copying credentials or real vault data.\nOfficial reference\nBitwarden — Onboarding and succession. Reviewed October 15, 2026.", "content_markdown": "A passwordless member can lose access to the entire account unless the documented transition is completed first.\n\n## Source facts\n\nBitwarden’s succession guide describes a specific removal risk for members who have no master password because they use SSO with trusted devices. Removing such a member eliminates account access unless account recovery first assigns a master password and the member signs in with that password at least once before removal. Without those steps, the guide says the removed user cannot simply rejoin and must delete the account and receive a new invitation. Revoking organization access also locks out the account until that access is restored.\n\nSource: [Bitwarden — Onboarding and succession](https://bitwarden.com/help/onboarding-and-succession/).\n\n## Applicability\n\nThis applies to the documented Bitwarden trusted-device account type without a master password. It is a planned account-transition issue, not a recommendation to preserve access during a security termination.\n\n## DSE recommendation\n\nDSE recommends identifying the member’s actual decryption and recovery state before a planned organization departure. Decide with the data owner whether the person is meant to retain an individual account and what data may remain there. If that transition is approved, follow the documented recovery and first-login sequence before removal, using protected credential handling. Keep the timing separate from any immediate security revocation requirement. Do not assume that sending another invitation will repair an account whose required transition was skipped.\n\n## Verification\n\nRehearse the approved sequence with a synthetic passwordless test account. Confirm the assigned master password works through an actual sign-in before removing the test membership. Verify the intended post-removal account behavior and retained organization ownership, then document the outcome without copying credentials or real vault data.\n\n## Official reference\n\n[Bitwarden — Onboarding and succession](https://bitwarden.com/help/onboarding-and-succession/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-nested-collection-no-access-inheritance/", "slug": "bitwarden-nested-collection-no-access-inheritance", "url": "https://update.dsesecurity.com/updates/bitwarden-nested-collection-no-access-inheritance/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-nested-collection-no-access-inheritance.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-nested-collection-no-access-inheritance/" }, "title": "Do not infer Bitwarden collection permissions from the folder-like hierarchy", "summary": "Nesting organizes the list; it does not copy a parent collection’s access or items.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:49+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 264, "potentially_affected": "This concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.", "dse_recommendation": "DSE recommends maintaining a collection-to-group access table independent of the visual hierarchy.", "primary_source": { "name": "Bitwarden — Collections", "url": "https://bitwarden.com/help/about-collections/", "published_on": null, "authority": "bitwarden.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Nesting organizes the list; it does not copy a parent collection’s access or items.
\nBitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.
\nSource: Bitwarden — Collections.
\nThis concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.
\nDSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.
\nCreate parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.
\nBitwarden — Collections. Reviewed October 15, 2026.
", "content_text": "Nesting organizes the list; it does not copy a parent collection’s access or items.\nSource facts\nBitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.\nSource: Bitwarden — Collections.\nApplicability\nThis concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.\nDSE recommendation\nDSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.\nVerification\nCreate parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.\nOfficial reference\nBitwarden — Collections. Reviewed October 15, 2026.", "content_markdown": "Nesting organizes the list; it does not copy a parent collection’s access or items.\n\n## Source facts\n\nBitwarden collections group organization-owned items for sharing, and the organization can assign access to users or groups. An organization-owned item must belong to at least one collection, while its ownership stays with the organization rather than an individual user. The documentation makes a specific distinction about nested collections: nesting changes how the collection list appears in the vault filter. It does not cause the child collection to inherit its parent’s items, access, or permissions. Those assignments must be configured independently.\n\nSource: [Bitwarden — Collections](https://bitwarden.com/help/about-collections/).\n\n## Applicability\n\nThis concerns Bitwarden organization collections and their visual nesting. Personal-vault folders, group membership, and organization administrative roles are separate concepts with different effects.\n\n## DSE recommendation\n\nDSE recommends maintaining a collection-to-group access table independent of the visual hierarchy. When creating a nested collection, review its explicit permissions and intended items instead of assuming the parent establishes a boundary. Use names that help users find information without implying inheritance that does not exist. During a restructure, check both old and new assignments before moving sensitive items. Keep organization ownership and collection access visible in the change record so a tidy-looking list does not hide unintended sharing.\n\n## Verification\n\nCreate parent and child test collections with different synthetic items and access groups. Confirm that access to the parent alone does not reveal the child’s items. Add the intended child assignment and retest. Review effective permissions through every relevant group and individual assignment before applying the structure to production data.\n\n## Official reference\n\n[Bitwarden — Collections](https://bitwarden.com/help/about-collections/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-trusted-device-per-app-approval/", "slug": "bitwarden-trusted-device-per-app-approval", "url": "https://update.dsesecurity.com/updates/bitwarden-trusted-device-per-app-approval/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-trusted-device-per-app-approval.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-trusted-device-per-app-approval/" }, "title": "Approve the Bitwarden app instance, not just the computer name", "summary": "The browser extension and desktop application on one computer are separate trusted devices.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:48+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 274, "potentially_affected": "This applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.", "dse_recommendation": "DSE recommends recording which app and browser profile a user is trying to approve.", "primary_source": { "name": "Bitwarden — Trusted devices", "url": "https://bitwarden.com/help/about-trusted-devices/", "published_on": null, "authority": "bitwarden.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The browser extension and desktop application on one computer are separate trusted devices.
\nBitwarden SSO with trusted devices separates SSO authentication from vault decryption using a device-stored key. A trusted device means an approved Bitwarden application instance, such as a browser extension or mobile app. Each app requires its own approval even when several apps run on one computer or phone. An untrusted app must obtain approval through an available method before it can decrypt the vault. The documentation describes approval from another device, administrator approval, or an existing master password where the account has one.
\nSource: Bitwarden — Trusted devices.
\nThis applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.
\nDSE recommends recording which app and browser profile a user is trying to approve. A request from a newly installed extension should not be dismissed simply because the same computer’s desktop app already works. Confirm the requester and the intended app instance using the approved identity process before accepting a request. Document available recovery methods for users without an established trusted app. Include browser-profile replacement, app reinstallations, and device retirement in user guidance so approval requests have an understandable operational context.
\nUse a controlled account to sign in through two separate Bitwarden apps on one test device. Confirm that approval of the first does not silently establish trust for the second. Review the approval method and verify that an unapproved app cannot decrypt the vault merely because SSO authentication succeeded.
\nBitwarden — Trusted devices. Reviewed October 15, 2026.
", "content_text": "The browser extension and desktop application on one computer are separate trusted devices.\nSource facts\nBitwarden SSO with trusted devices separates SSO authentication from vault decryption using a device-stored key. A trusted device means an approved Bitwarden application instance, such as a browser extension or mobile app. Each app requires its own approval even when several apps run on one computer or phone. An untrusted app must obtain approval through an available method before it can decrypt the vault. The documentation describes approval from another device, administrator approval, or an existing master password where the account has one.\nSource: Bitwarden — Trusted devices.\nApplicability\nThis applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.\nDSE recommendation\nDSE recommends recording which app and browser profile a user is trying to approve. A request from a newly installed extension should not be dismissed simply because the same computer’s desktop app already works. Confirm the requester and the intended app instance using the approved identity process before accepting a request. Document available recovery methods for users without an established trusted app. Include browser-profile replacement, app reinstallations, and device retirement in user guidance so approval requests have an understandable operational context.\nVerification\nUse a controlled account to sign in through two separate Bitwarden apps on one test device. Confirm that approval of the first does not silently establish trust for the second. Review the approval method and verify that an unapproved app cannot decrypt the vault merely because SSO authentication succeeded.\nOfficial reference\nBitwarden — Trusted devices. Reviewed October 15, 2026.", "content_markdown": "The browser extension and desktop application on one computer are separate trusted devices.\n\n## Source facts\n\nBitwarden SSO with trusted devices separates SSO authentication from vault decryption using a device-stored key. A trusted device means an approved Bitwarden application instance, such as a browser extension or mobile app. Each app requires its own approval even when several apps run on one computer or phone. An untrusted app must obtain approval through an available method before it can decrypt the vault. The documentation describes approval from another device, administrator approval, or an existing master password where the account has one.\n\nSource: [Bitwarden — Trusted devices](https://bitwarden.com/help/about-trusted-devices/).\n\n## Applicability\n\nThis applies to organizations using Bitwarden SSO with trusted devices. It is different from a computer’s inventory status, browser profile management, or an identity provider’s own trusted-device flag.\n\n## DSE recommendation\n\nDSE recommends recording which app and browser profile a user is trying to approve. A request from a newly installed extension should not be dismissed simply because the same computer’s desktop app already works. Confirm the requester and the intended app instance using the approved identity process before accepting a request. Document available recovery methods for users without an established trusted app. Include browser-profile replacement, app reinstallations, and device retirement in user guidance so approval requests have an understandable operational context.\n\n## Verification\n\nUse a controlled account to sign in through two separate Bitwarden apps on one test device. Confirm that approval of the first does not silently establish trust for the second. Review the approval method and verify that an unapproved app cannot decrypt the vault merely because SSO authentication succeeded.\n\n## Official reference\n\n[Bitwarden — Trusted devices](https://bitwarden.com/help/about-trusted-devices/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/bitwarden-event-log-client-delay-coverage-limits/", "slug": "bitwarden-event-log-client-delay-coverage-limits", "url": "https://update.dsesecurity.com/updates/bitwarden-event-log-client-delay-coverage-limits/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/bitwarden-event-log-client-delay-coverage-limits.md", "json": "https://update.dsesecurity.com/api/v1/posts/bitwarden-event-log-client-delay-coverage-limits/" }, "title": "Interpret missing Bitwarden events with the client-reporting limits in mind", "summary": "An empty event search does not prove that an offline client performed no action.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:47+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "This applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.", "dse_recommendation": "DSE recommends defining which event types an investigation requires before exporting logs.", "primary_source": { "name": "Bitwarden — Event logs", "url": "https://bitwarden.com/help/event-logs/", "published_on": null, "authority": "bitwarden.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An empty event search does not prove that an offline client performed no action.
\nBitwarden organization event logs include timestamped activity and can be viewed or exported through documented web and API interfaces. The documentation distinguishes server events, which are saved immediately, from client events, which are normally transmitted periodically. A disconnected client cannot report events, and altered clients can suppress or modify reporting. Bitwarden explicitly cautions that these logs may not satisfy every forensic or auditing requirement. The event viewer also limits the date span displayed at one time even though the documented retention is longer.
\nSource: Bitwarden — Event logs.
\nThis applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.
\nDSE recommends defining which event types an investigation requires before exporting logs. Allow for normal client-reporting delay, and compare the requested time range with the viewer’s limits. Preserve relevant account, device, and application evidence through the appropriate process when a missing event matters. Document the distinction between “no matching record found” and “the action did not occur.” Review API export access and protected storage for event data, and correlate organization changes with independent identity or endpoint records where appropriate.
\nWith a test account and synthetic vault item, perform a documented client event and compare its appearance with a server-side change. Observe reporting timing without assuming a fixed maximum. Confirm the export covers the requested period and record any known disconnected-client interval as an evidence limitation.
\nBitwarden — Event logs. Reviewed October 15, 2026.
", "content_text": "An empty event search does not prove that an offline client performed no action.\nSource facts\nBitwarden organization event logs include timestamped activity and can be viewed or exported through documented web and API interfaces. The documentation distinguishes server events, which are saved immediately, from client events, which are normally transmitted periodically. A disconnected client cannot report events, and altered clients can suppress or modify reporting. Bitwarden explicitly cautions that these logs may not satisfy every forensic or auditing requirement. The event viewer also limits the date span displayed at one time even though the documented retention is longer.\nSource: Bitwarden — Event logs.\nApplicability\nThis applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.\nDSE recommendation\nDSE recommends defining which event types an investigation requires before exporting logs. Allow for normal client-reporting delay, and compare the requested time range with the viewer’s limits. Preserve relevant account, device, and application evidence through the appropriate process when a missing event matters. Document the distinction between “no matching record found” and “the action did not occur.” Review API export access and protected storage for event data, and correlate organization changes with independent identity or endpoint records where appropriate.\nVerification\nWith a test account and synthetic vault item, perform a documented client event and compare its appearance with a server-side change. Observe reporting timing without assuming a fixed maximum. Confirm the export covers the requested period and record any known disconnected-client interval as an evidence limitation.\nOfficial reference\nBitwarden — Event logs. Reviewed October 15, 2026.", "content_markdown": "An empty event search does not prove that an offline client performed no action.\n\n## Source facts\n\nBitwarden organization event logs include timestamped activity and can be viewed or exported through documented web and API interfaces. The documentation distinguishes server events, which are saved immediately, from client events, which are normally transmitted periodically. A disconnected client cannot report events, and altered clients can suppress or modify reporting. Bitwarden explicitly cautions that these logs may not satisfy every forensic or auditing requirement. The event viewer also limits the date span displayed at one time even though the documented retention is longer.\n\nSource: [Bitwarden — Event logs](https://bitwarden.com/help/event-logs/).\n\n## Applicability\n\nThis applies to organization event logs on eligible Bitwarden plans. It does not establish a complete endpoint audit trail or guarantee that every offline or tampered-client action is represented.\n\n## DSE recommendation\n\nDSE recommends defining which event types an investigation requires before exporting logs. Allow for normal client-reporting delay, and compare the requested time range with the viewer’s limits. Preserve relevant account, device, and application evidence through the appropriate process when a missing event matters. Document the distinction between “no matching record found” and “the action did not occur.” Review API export access and protected storage for event data, and correlate organization changes with independent identity or endpoint records where appropriate.\n\n## Verification\n\nWith a test account and synthetic vault item, perform a documented client event and compare its appearance with a server-side change. Observe reporting timing without assuming a fixed maximum. Confirm the export covers the requested period and record any known disconnected-client interval as an evidence limitation.\n\n## Official reference\n\n[Bitwarden — Event logs](https://bitwarden.com/help/event-logs/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries/", "slug": "gitlab-secure-files-log-access-audit-boundaries", "url": "https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-secure-files-log-access-audit-boundaries.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-secure-files-log-access-audit-boundaries/" }, "title": "Review GitLab Secure Files access and logging before storing signing material", "summary": "Secure Files encrypts stored files, but job output and project access still need explicit review.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:46+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 275, "potentially_affected": "This applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.", "dse_recommendation": "DSE recommends treating storage protection, job exposure, and audit evidence as separate requirements.", "primary_source": { "name": "GitLab — Secure Files", "url": "https://docs.gitlab.com/ci/secure_files/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Secure Files encrypts stored files, but job output and project access still need explicit review.
\nGitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.
\nSource: GitLab — Secure Files.
\nThis applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.
\nDSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.
\nUse a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.
\nGitLab — Secure Files. Reviewed October 15, 2026.
", "content_text": "Secure Files encrypts stored files, but job output and project access still need explicit review.\nSource facts\nGitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.\nSource: GitLab — Secure Files.\nApplicability\nThis applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.\nDSE recommendation\nDSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.\nVerification\nUse a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.\nOfficial reference\nGitLab — Secure Files. Reviewed October 15, 2026.", "content_markdown": "Secure Files encrypts stored files, but job output and project access still need explicit review.\n\n## Source facts\n\nGitLab project-level Secure Files stores files outside the repository and does not version-control them. The documented feature accepts text and binary files within its size limit. Uploaded files are encrypted, and the current glab download command verifies their recorded checksum. However, contents printed by a job are not masked in the job log. Project members with Developer, Maintainer, or Owner roles can access the files. GitLab also documents that interactions with project-level Secure Files are not included in audit events.\n\nSource: [GitLab — Secure Files](https://docs.gitlab.com/ci/secure_files/).\n\n## Applicability\n\nThis applies to GitLab project-level Secure Files, not CI variables or an external secrets manager. Verify current version support and the privileges of every project member before selecting this mechanism.\n\n## DSE recommendation\n\nDSE recommends treating storage protection, job exposure, and audit evidence as separate requirements. Store only material intended for the project’s authorized developer population. Download the specific required file to a controlled job path, and prevent scripts or debugging output from printing its contents. Keep a separate owner-approved change record for rotations because repository history and Secure Files audit events will not supply that record. Review runner persistence and artifact paths so a downloaded private key does not escape through a cache or build archive.\n\n## Verification\n\nUse a harmless test file to confirm download checksum verification and identify which roles can retrieve it. Review job logs and resulting artifacts for accidental inclusion. Confirm the rotation record can identify the approved replacement without expecting a Secure Files audit event that the feature does not provide.\n\n## Official reference\n\n[GitLab — Secure Files](https://docs.gitlab.com/ci/secure_files/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-ci-inputs-creation-time-validation-scope/", "slug": "gitlab-ci-inputs-creation-time-validation-scope", "url": "https://update.dsesecurity.com/updates/gitlab-ci-inputs-creation-time-validation-scope/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-ci-inputs-creation-time-validation-scope.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-ci-inputs-creation-time-validation-scope/" }, "title": "Validate GitLab pipeline options at creation time with typed inputs", "summary": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:45+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 273, "potentially_affected": "This covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.", "dse_recommendation": "DSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode.", "primary_source": { "name": "GitLab — CI/CD inputs", "url": "https://docs.gitlab.com/ci/inputs/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.
\nGitLab CI/CD inputs provide typed parameters and validation when a pipeline is created. Their values are interpolated at initialization and remain fixed for the pipeline run. Inputs can restrict values through types, predefined options, and regular expressions. Their scope is the configuration file where they are defined; another included file or downstream pipeline needs an explicit input handoff. An input without a default is mandatory. GitLab warns that automatically triggered pipelines can fail to start if required inputs have no available values.
\nSource: GitLab — CI/CD inputs.
\nThis covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.
\nDSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode. Define the smallest useful option set and describe the consequence of each choice in plain language. Review how manual, scheduled, merge-request, and downstream pipelines obtain their values. Choose safe defaults only where the workflow allows them; otherwise provide an explicit required value through the calling configuration. Keep credentials in the approved secret mechanism and review the scripts that consume inputs as carefully as other pipeline code.
\nTest one valid option, an invalid value, and a missing mandatory input in a nonproduction pipeline. Confirm that validation occurs before jobs run. Exercise an included configuration and a downstream pipeline to verify explicit input passing, and check every automatic trigger path the project actually uses.
\nGitLab — CI/CD inputs. Reviewed October 15, 2026.
", "content_text": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.\nSource facts\nGitLab CI/CD inputs provide typed parameters and validation when a pipeline is created. Their values are interpolated at initialization and remain fixed for the pipeline run. Inputs can restrict values through types, predefined options, and regular expressions. Their scope is the configuration file where they are defined; another included file or downstream pipeline needs an explicit input handoff. An input without a default is mandatory. GitLab warns that automatically triggered pipelines can fail to start if required inputs have no available values.\nSource: GitLab — CI/CD inputs.\nApplicability\nThis covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.\nDSE recommendation\nDSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode. Define the smallest useful option set and describe the consequence of each choice in plain language. Review how manual, scheduled, merge-request, and downstream pipelines obtain their values. Choose safe defaults only where the workflow allows them; otherwise provide an explicit required value through the calling configuration. Keep credentials in the approved secret mechanism and review the scripts that consume inputs as carefully as other pipeline code.\nVerification\nTest one valid option, an invalid value, and a missing mandatory input in a nonproduction pipeline. Confirm that validation occurs before jobs run. Exercise an included configuration and a downstream pipeline to verify explicit input passing, and check every automatic trigger path the project actually uses.\nOfficial reference\nGitLab — CI/CD inputs. Reviewed October 15, 2026.", "content_markdown": "Typed inputs can reject invalid pipeline choices before jobs begin, but they are not runtime variables.\n\n## Source facts\n\nGitLab CI/CD inputs provide typed parameters and validation when a pipeline is created. Their values are interpolated at initialization and remain fixed for the pipeline run. Inputs can restrict values through types, predefined options, and regular expressions. Their scope is the configuration file where they are defined; another included file or downstream pipeline needs an explicit input handoff. An input without a default is mandatory. GitLab warns that automatically triggered pipelines can fail to start if required inputs have no available values.\n\nSource: [GitLab — CI/CD inputs](https://docs.gitlab.com/ci/inputs/).\n\n## Applicability\n\nThis covers GitLab CI/CD input configuration on supported versions. It does not make arbitrary script interpolation safe or turn user-supplied pipeline options into protected secret storage.\n\n## DSE recommendation\n\nDSE recommends using bounded inputs for operational choices such as an approved environment or deployment mode. Define the smallest useful option set and describe the consequence of each choice in plain language. Review how manual, scheduled, merge-request, and downstream pipelines obtain their values. Choose safe defaults only where the workflow allows them; otherwise provide an explicit required value through the calling configuration. Keep credentials in the approved secret mechanism and review the scripts that consume inputs as carefully as other pipeline code.\n\n## Verification\n\nTest one valid option, an invalid value, and a missing mandatory input in a nonproduction pipeline. Confirm that validation occurs before jobs run. Exercise an included configuration and a downstream pipeline to verify explicit input passing, and check every automatic trigger path the project actually uses.\n\n## Official reference\n\n[GitLab — CI/CD inputs](https://docs.gitlab.com/ci/inputs/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-job-artifact-expiry-keep-latest-exceptions/", "slug": "gitlab-job-artifact-expiry-keep-latest-exceptions", "url": "https://update.dsesecurity.com/updates/gitlab-job-artifact-expiry-keep-latest-exceptions/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-job-artifact-expiry-keep-latest-exceptions.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-job-artifact-expiry-keep-latest-exceptions/" }, "title": "Check GitLab’s keep-latest behavior before relying on artifact expiry", "summary": "An expire_in value alone does not describe the retention of every pipeline artifact.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:44+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 269, "potentially_affected": "This applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.", "dse_recommendation": "DSE recommends separating temporary pipeline handoffs from distributable releases.", "primary_source": { "name": "GitLab — Job artifacts", "url": "https://docs.gitlab.com/ci/jobs/job_artifacts/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An expire_in value alone does not describe the retention of every pipeline artifact.
\nGitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.
\nSource: GitLab — Job artifacts.
\nThis applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.
\nDSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.
\nCreate harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.
\nGitLab — Job artifacts. Reviewed October 15, 2026.
", "content_text": "An expire_in value alone does not describe the retention of every pipeline artifact.\nSource facts\nGitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.\nSource: GitLab — Job artifacts.\nApplicability\nThis applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.\nDSE recommendation\nDSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.\nVerification\nCreate harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.\nOfficial reference\nGitLab — Job artifacts. Reviewed October 15, 2026.", "content_markdown": "An expire_in value alone does not describe the retention of every pipeline artifact.\n\n## Source facts\n\nGitLab job artifacts can have an expire_in setting; otherwise the instance default applies. The current documentation states that artifacts from the latest pipeline on each reference and the most recent successful pipeline can be preserved regardless of that expiry. Disabling the keep-latest behavior makes new artifacts follow their configured expiry, while older preserved artifacts may remain until another pipeline runs for the same reference. A latest-artifact URL also changes its target as new pipelines run, so it is not a fixed release identifier.\n\nSource: [GitLab — Job artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/).\n\n## Applicability\n\nThis applies to GitLab job-artifact retention and download behavior as documented on review. Check the installed version and project or instance settings before forecasting storage reclamation.\n\n## DSE recommendation\n\nDSE recommends separating temporary pipeline handoffs from distributable releases. Record the desired retention, the keep-latest setting, and whether a branch is likely to run another pipeline. Review artifact contents for accidental credential or customer-data inclusion before retention changes. Use an appropriate versioned release store for outputs that must have a stable identity, rather than relying on a moving latest-job link. Obtain the required retention decision before deleting artifacts, and account for job logs or report data that may also be affected.\n\n## Verification\n\nCreate harmless artifacts on a test reference, observe the relevant keep-latest behavior, then run a newer pipeline and review which artifacts become eligible to expire. Check the resolved target of a latest URL. Record settings and timing without interpreting “eligible for expiry” as immediate guaranteed disk reclamation.\n\n## Official reference\n\n[GitLab — Job artifacts](https://docs.gitlab.com/ci/jobs/job_artifacts/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy/", "slug": "gitlab-shared-runner-private-image-pull-policy", "url": "https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-shared-runner-private-image-pull-policy.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-shared-runner-private-image-pull-policy/" }, "title": "Prevent a shared GitLab runner from reusing another project’s private image without a registry check", "summary": "The if-not-present pull policy can cross an authorization boundary through the local image cache.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:43+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 266, "potentially_affected": "This concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.", "dse_recommendation": "DSE recommends documenting which users and projects share each runner and who controls image selection.", "primary_source": { "name": "GitLab — Runner security", "url": "https://docs.gitlab.com/runner/security/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The if-not-present pull policy can cross an authorization boundary through the local image cache.
\nGitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.
\nSource: GitLab — Runner security.
\nThis concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.
\nDSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.
\nUsing a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.
\nGitLab — Runner security. Reviewed October 15, 2026.
", "content_text": "The if-not-present pull policy can cross an authorization boundary through the local image cache.\nSource facts\nGitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.\nSource: GitLab — Runner security.\nApplicability\nThis concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.\nDSE recommendation\nDSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.\nVerification\nUsing a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.\nOfficial reference\nGitLab — Runner security. Reviewed October 15, 2026.", "content_markdown": "The if-not-present pull policy can cross an authorization boundary through the local image cache.\n\n## Source facts\n\nGitLab’s runner security guide describes a private-image risk on shared runners. One user’s authorized job can pull an image into the runner’s local cache. A later user without registry access can request that image and receive the cached copy when the pull policy is if-not-present. GitLab recommends always for mixed-trust runners where users may request registry images, and reserves if-not-present for trusted dedicated use. The guide also distinguishes never for an administrator-controlled set of images already present on the runner.\n\nSource: [GitLab — Runner security](https://docs.gitlab.com/runner/security/).\n\n## Applicability\n\nThis concerns self-managed GitLab runners using the relevant container executors and pull policies. It is an image-access review, not a claim that one pull-policy setting provides complete job or host isolation.\n\n## DSE recommendation\n\nDSE recommends documenting which users and projects share each runner and who controls image selection. For mixed-trust use, require an appropriate registry authorization check instead of silently trusting a cached private image. For a deliberately fixed image set, review the administrator-maintained model separately. Inspect runner configuration, allowed policies, and job overrides together. Keep credential helpers and host-side registry configuration in the broader runner security review, and consider dedicated execution capacity for workloads with incompatible trust requirements.\n\n## Verification\n\nUsing a disposable private image and two test identities, verify the chosen policy with a warm cache and with no cache. Confirm that an identity lacking registry permission cannot obtain the cached private image through the shared runner. Remove the test image and credentials afterward.\n\n## Official reference\n\n[GitLab — Runner security](https://docs.gitlab.com/runner/security/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-deployment-approval-manual-job-start/", "slug": "gitlab-deployment-approval-manual-job-start", "url": "https://update.dsesecurity.com/updates/gitlab-deployment-approval-manual-job-start/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-deployment-approval-manual-job-start.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-deployment-approval-manual-job-start/" }, "title": "Explain why an approved GitLab deployment may still be waiting to run", "summary": "Approval satisfies the release gate; the deployment job still requires a separate start.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:42+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 258, "potentially_affected": "This concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.", "dse_recommendation": "DSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment.", "primary_source": { "name": "GitLab — Deployment approvals", "url": "https://docs.gitlab.com/ci/environments/deployment_approvals/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Approval satisfies the release gate; the deployment job still requires a separate start.
\nGitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.
\nSource: GitLab — Deployment approvals.
\nThis concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.
\nDSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.
\nIn a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.
\nGitLab — Deployment approvals. Reviewed October 15, 2026.
", "content_text": "Approval satisfies the release gate; the deployment job still requires a separate start.\nSource facts\nGitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.\nSource: GitLab — Deployment approvals.\nApplicability\nThis concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.\nDSE recommendation\nDSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.\nVerification\nIn a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.\nOfficial reference\nGitLab — Deployment approvals. Reviewed October 15, 2026.", "content_markdown": "Approval satisfies the release gate; the deployment job still requires a separate start.\n\n## Source facts\n\nGitLab deployment approvals block jobs targeting protected environments until the required approvals are granted. The deployment job does not have to be configured as a manual job for the approval gate to apply. After approval, however, the documentation requires an operator to run the job manually; approval alone does not start it. A person can provide only one approval per deployment even when they belong to several approver groups. By default, the user who triggered the pipeline cannot approve that deployment.\n\nSource: [GitLab — Deployment approvals](https://docs.gitlab.com/ci/environments/deployment_approvals/).\n\n## Applicability\n\nThis concerns GitLab deployment approvals on supported Premium or Ultimate environments. Pipeline status, environment protection, approval eligibility, and permission to execute the job are related but separate checks.\n\n## DSE recommendation\n\nDSE recommends making the release procedure explicit about who approves and who starts the reviewed deployment. Present a release record that identifies the pipeline, commit, environment, required approvals, and final execution step. Avoid repeatedly creating pipelines when the existing job is simply waiting for its authorized start. Review overlapping approver-group membership so the requested approval count can actually be satisfied. Keep self-approval settings deliberate, and revisit approval rules promptly when staff move or their access changes.\n\n## Verification\n\nIn a test protected environment, observe the blocked job before approval and its state after approval. Confirm that it runs only after the intended operator starts it. Use overlapping test group memberships to verify the one-approval-per-person behavior and record the resulting approval history.\n\n## Official reference\n\n[GitLab — Deployment approvals](https://docs.gitlab.com/ci/environments/deployment_approvals/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-protected-environment-deployment-only-groups/", "slug": "gitlab-protected-environment-deployment-only-groups", "url": "https://update.dsesecurity.com/updates/gitlab-protected-environment-deployment-only-groups/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-protected-environment-deployment-only-groups.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-protected-environment-deployment-only-groups/" }, "title": "Grant GitLab deployment-only access without broadening repository permissions", "summary": "An invited Reporter group can be used for deployment access while repository write authority stays separate.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:41+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 262, "potentially_affected": "This applies to GitLab protected environments and deployment-only group access. It does not confer branch-write permission, operating-system access, or authorization inside the application being deployed.", "dse_recommendation": "DSE recommends defining the release operator’s exact responsibility before assigning a broad project role.", "primary_source": { "name": "GitLab — Protected environments", "url": "https://docs.gitlab.com/ci/environments/protected_environments/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An invited Reporter group can be used for deployment access while repository write authority stays separate.
\nGitLab protected environments control who may deploy to an environment. The documentation describes deployment-only access for users who can deploy but lack push or merge permission on the deployed branch. Reporter-role users receive protected-environment access through group membership rather than individual selection. Invited groups can appear in the Allowed to deploy list. The environment relationship must be represented by the deployment job’s configuration; GitLab needs that association to apply the protected-environment authorization model. Protected environments are documented for Premium and Ultimate.
\nSource: GitLab — Protected environments.
\nThis applies to GitLab protected environments and deployment-only group access. It does not confer branch-write permission, operating-system access, or authorization inside the application being deployed.
\nDSE recommends defining the release operator’s exact responsibility before assigning a broad project role. Keep repository authorship, release approval, and job execution as separate permission decisions. Document the invited group, environment name, and deployment job that connects them. Review group inheritance and other project memberships so an intended deployment-only operator does not gain write access through another path. Preserve a clear owner for the protected environment and recheck these relationships when renaming environments or restructuring groups.
\nWith a test Reporter-group member, verify that the intended deployment job can be started while repository push and merge remain unavailable. Compare a user outside the group. Confirm the job is associated with the correct protected environment and review the effective access from all memberships.
\nGitLab — Protected environments. Reviewed October 15, 2026.
", "content_text": "An invited Reporter group can be used for deployment access while repository write authority stays separate.\nSource facts\nGitLab protected environments control who may deploy to an environment. The documentation describes deployment-only access for users who can deploy but lack push or merge permission on the deployed branch. Reporter-role users receive protected-environment access through group membership rather than individual selection. Invited groups can appear in the Allowed to deploy list. The environment relationship must be represented by the deployment job’s configuration; GitLab needs that association to apply the protected-environment authorization model. Protected environments are documented for Premium and Ultimate.\nSource: GitLab — Protected environments.\nApplicability\nThis applies to GitLab protected environments and deployment-only group access. It does not confer branch-write permission, operating-system access, or authorization inside the application being deployed.\nDSE recommendation\nDSE recommends defining the release operator’s exact responsibility before assigning a broad project role. Keep repository authorship, release approval, and job execution as separate permission decisions. Document the invited group, environment name, and deployment job that connects them. Review group inheritance and other project memberships so an intended deployment-only operator does not gain write access through another path. Preserve a clear owner for the protected environment and recheck these relationships when renaming environments or restructuring groups.\nVerification\nWith a test Reporter-group member, verify that the intended deployment job can be started while repository push and merge remain unavailable. Compare a user outside the group. Confirm the job is associated with the correct protected environment and review the effective access from all memberships.\nOfficial reference\nGitLab — Protected environments. Reviewed October 15, 2026.", "content_markdown": "An invited Reporter group can be used for deployment access while repository write authority stays separate.\n\n## Source facts\n\nGitLab protected environments control who may deploy to an environment. The documentation describes deployment-only access for users who can deploy but lack push or merge permission on the deployed branch. Reporter-role users receive protected-environment access through group membership rather than individual selection. Invited groups can appear in the Allowed to deploy list. The environment relationship must be represented by the deployment job’s configuration; GitLab needs that association to apply the protected-environment authorization model. Protected environments are documented for Premium and Ultimate.\n\nSource: [GitLab — Protected environments](https://docs.gitlab.com/ci/environments/protected_environments/).\n\n## Applicability\n\nThis applies to GitLab protected environments and deployment-only group access. It does not confer branch-write permission, operating-system access, or authorization inside the application being deployed.\n\n## DSE recommendation\n\nDSE recommends defining the release operator’s exact responsibility before assigning a broad project role. Keep repository authorship, release approval, and job execution as separate permission decisions. Document the invited group, environment name, and deployment job that connects them. Review group inheritance and other project memberships so an intended deployment-only operator does not gain write access through another path. Preserve a clear owner for the protected environment and recheck these relationships when renaming environments or restructuring groups.\n\n## Verification\n\nWith a test Reporter-group member, verify that the intended deployment job can be started while repository push and merge remain unavailable. Compare a user outside the group. Confirm the job is associated with the correct protected environment and review the effective access from all memberships.\n\n## Official reference\n\n[GitLab — Protected environments](https://docs.gitlab.com/ci/environments/protected_environments/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-masked-protected-variables-pipeline-code-review/", "slug": "gitlab-masked-protected-variables-pipeline-code-review", "url": "https://update.dsesecurity.com/updates/gitlab-masked-protected-variables-pipeline-code-review/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-masked-protected-variables-pipeline-code-review.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-masked-protected-variables-pipeline-code-review/" }, "title": "Review pipeline code even when GitLab variables are masked and protected", "summary": "Masking changes log display; it does not make untrusted job code safe to execute with a secret.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:40+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 274, "potentially_affected": "This concerns GitLab CI/CD variable visibility and availability controls. Exact options depend on the GitLab version and pipeline type; separately review the current rules for merge-request and fork pipelines.", "dse_recommendation": "DSE recommends reviewing every pipeline change before running it with production credentials, including included configuration and scripts it invokes.", "primary_source": { "name": "GitLab — CI/CD variables", "url": "https://docs.gitlab.com/ci/variables/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Masking changes log display; it does not make untrusted job code safe to execute with a secret.
\nGitLab warns that malicious CI/CD code can compromise both masked and protected variables. Masking replaces matching values in job logs, but transformed output may evade that replacement. Hidden variables additionally prevent later revelation through the settings page; they do not remove a job’s ability to use the value. Protected variables limit availability to protected branches or tags. GitLab also notes that running a parent-project merge-request pipeline for a fork can make the parent project’s variables available to that pipeline.
\nSource: GitLab — CI/CD variables.
\nThis concerns GitLab CI/CD variable visibility and availability controls. Exact options depend on the GitLab version and pipeline type; separately review the current rules for merge-request and fork pipelines.
\nDSE recommends reviewing every pipeline change before running it with production credentials, including included configuration and scripts it invokes. Keep secret availability narrow by environment, project, and protected execution path. Use an approved external secret integration where appropriate, but still review the code receiving the secret. Treat debugging output and service logs as potential exposure paths. If a job is suspected of disclosure, follow the credential-rotation process rather than relying on a masked log as evidence that the secret never left the runner.
\nUse a harmless synthetic value in a test pipeline to compare normal masked output with transformed output. Check protected and unprotected execution paths and the intended fork workflow. Confirm the reviewer can identify which code executes before any real secret is made available.
\nGitLab — CI/CD variables. Reviewed October 15, 2026.
", "content_text": "Masking changes log display; it does not make untrusted job code safe to execute with a secret.\nSource facts\nGitLab warns that malicious CI/CD code can compromise both masked and protected variables. Masking replaces matching values in job logs, but transformed output may evade that replacement. Hidden variables additionally prevent later revelation through the settings page; they do not remove a job’s ability to use the value. Protected variables limit availability to protected branches or tags. GitLab also notes that running a parent-project merge-request pipeline for a fork can make the parent project’s variables available to that pipeline.\nSource: GitLab — CI/CD variables.\nApplicability\nThis concerns GitLab CI/CD variable visibility and availability controls. Exact options depend on the GitLab version and pipeline type; separately review the current rules for merge-request and fork pipelines.\nDSE recommendation\nDSE recommends reviewing every pipeline change before running it with production credentials, including included configuration and scripts it invokes. Keep secret availability narrow by environment, project, and protected execution path. Use an approved external secret integration where appropriate, but still review the code receiving the secret. Treat debugging output and service logs as potential exposure paths. If a job is suspected of disclosure, follow the credential-rotation process rather than relying on a masked log as evidence that the secret never left the runner.\nVerification\nUse a harmless synthetic value in a test pipeline to compare normal masked output with transformed output. Check protected and unprotected execution paths and the intended fork workflow. Confirm the reviewer can identify which code executes before any real secret is made available.\nOfficial reference\nGitLab — CI/CD variables. Reviewed October 15, 2026.", "content_markdown": "Masking changes log display; it does not make untrusted job code safe to execute with a secret.\n\n## Source facts\n\nGitLab warns that malicious CI/CD code can compromise both masked and protected variables. Masking replaces matching values in job logs, but transformed output may evade that replacement. Hidden variables additionally prevent later revelation through the settings page; they do not remove a job’s ability to use the value. Protected variables limit availability to protected branches or tags. GitLab also notes that running a parent-project merge-request pipeline for a fork can make the parent project’s variables available to that pipeline.\n\nSource: [GitLab — CI/CD variables](https://docs.gitlab.com/ci/variables/).\n\n## Applicability\n\nThis concerns GitLab CI/CD variable visibility and availability controls. Exact options depend on the GitLab version and pipeline type; separately review the current rules for merge-request and fork pipelines.\n\n## DSE recommendation\n\nDSE recommends reviewing every pipeline change before running it with production credentials, including included configuration and scripts it invokes. Keep secret availability narrow by environment, project, and protected execution path. Use an approved external secret integration where appropriate, but still review the code receiving the secret. Treat debugging output and service logs as potential exposure paths. If a job is suspected of disclosure, follow the credential-rotation process rather than relying on a masked log as evidence that the secret never left the runner.\n\n## Verification\n\nUse a harmless synthetic value in a test pipeline to compare normal masked output with transformed output. Check protected and unprotected execution paths and the intended fork workflow. Confirm the reviewer can identify which code executes before any real secret is made available.\n\n## Official reference\n\n[GitLab — CI/CD variables](https://docs.gitlab.com/ci/variables/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/", "slug": "gitlab-job-token-allowlist-user-permission-gates", "url": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/gitlab-job-token-allowlist-user-permission-gates.md", "json": "https://update.dsesecurity.com/api/v1/posts/gitlab-job-token-allowlist-user-permission-gates/" }, "title": "Treat a GitLab job-token allowlist as a second gate, not a permission grant", "summary": "Cross-project job access requires an allowed source and an already-authorized triggering user.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:39+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 264, "potentially_affected": "This applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.", "dse_recommendation": "DSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline.", "primary_source": { "name": "GitLab — CI/CD job token", "url": "https://docs.gitlab.com/ci/jobs/ci_job_token/", "published_on": null, "authority": "docs.gitlab.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Cross-project job access requires an allowed source and an already-authorized triggering user.
\nGitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.
\nSource: GitLab — CI/CD job token.
\nThis applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.
\nDSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.
\nTest the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.
\nGitLab — CI/CD job token. Reviewed October 15, 2026.
", "content_text": "Cross-project job access requires an allowed source and an already-authorized triggering user.\nSource facts\nGitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.\nSource: GitLab — CI/CD job token.\nApplicability\nThis applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.\nDSE recommendation\nDSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.\nVerification\nTest the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.\nOfficial reference\nGitLab — CI/CD job token. Reviewed October 15, 2026.", "content_markdown": "Cross-project job access requires an allowed source and an already-authorized triggering user.\n\n## Source facts\n\nGitLab creates a CI_JOB_TOKEN for a running job and revokes its access when the job finishes. The token has access to fewer resources than a personal access token and is constrained by the triggering user’s permissions. For cross-project access, the target project’s allowlist normally must include the source project or group. Adding that source does not grant its users additional project privileges. A group entry includes projects in its subgroups and can also cover projects added to that group later.\n\nSource: [GitLab — CI/CD job token](https://docs.gitlab.com/ci/jobs/ci_job_token/).\n\n## Applicability\n\nThis applies to GitLab CI/CD job-token access. Public or internal project features can have additional visibility behavior, and self-managed administrators can enforce stricter allowlist requirements.\n\n## DSE recommendation\n\nDSE recommends reviewing the source project and triggering identity together when approving a cross-project pipeline. Prefer the narrowest practical source entry, especially where a group contains unrelated projects or can gain new descendants. Record which target resources the integration needs and why its users have permission. Keep a minimal test job for access verification, and review group membership changes as part of the trust relationship. Avoid disabling the allowlist to solve a missing user privilege or an incorrectly scoped integration.\n\n## Verification\n\nTest the approved source with an authorized user, then compare an unlisted source and a triggering identity without the target privilege. Confirm the expected denials. Review the authentication log and ensure the token cannot be reused after the test job completes.\n\n## Official reference\n\n[GitLab — CI/CD job token](https://docs.gitlab.com/ci/jobs/ci_job_token/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/pfsense-multiwan-local-vpn-policy-route-bypass/", "slug": "pfsense-multiwan-local-vpn-policy-route-bypass", "url": "https://update.dsesecurity.com/updates/pfsense-multiwan-local-vpn-policy-route-bypass/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/pfsense-multiwan-local-vpn-policy-route-bypass.md", "json": "https://update.dsesecurity.com/api/v1/posts/pfsense-multiwan-local-vpn-policy-route-bypass/" }, "title": "Keep local and VPN traffic above pfSense Multi-WAN policy-routing rules", "summary": "A gateway on a broad pass rule can send traffic away from routes that should remain local.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:36+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 271, "potentially_affected": "This concerns pfSense Multi-WAN rules on the relevant ingress interface. The actual destinations and route exceptions must come from the approved network design rather than a copied example address list.", "dse_recommendation": "DSE recommends building an explicit exception list for internal services, remote VPN networks, and other destinations that should follow the routing table.", "primary_source": { "name": "Netgate — Policy routing", "url": "https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html", "published_on": null, "authority": "docs.netgate.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A gateway on a broad pass rule can send traffic away from routes that should remain local.
\nIn pfSense, selecting a gateway or gateway group on a firewall rule policy-routes matching traffic through that selection. Netgate states that traffic intended for other local interfaces, VPNs, MPLS, or normal routing-table decisions must bypass policy routing. The documented method places a matching rule without a selected gateway above the broader gateway-bearing rule. Rule order matters because the first match is used. Netgate also documents additional handling when traffic must stop rather than fall through to another route after a selected gateway fails.
\nSource: Netgate — Policy routing.
\nThis concerns pfSense Multi-WAN rules on the relevant ingress interface. The actual destinations and route exceptions must come from the approved network design rather than a copied example address list.
\nDSE recommends building an explicit exception list for internal services, remote VPN networks, and other destinations that should follow the routing table. Review that list before changing a default pass rule to use a WAN group. Keep the exception rule immediately understandable and document why each destination belongs there. Decide separately which traffic may fail over and which must fail closed. Preserve the previous rule order for rollback, and coordinate testing with owners of remote management and site-to-site applications.
\nTest an approved local service, a VPN destination, and an internet destination from the same client. Confirm the intended path for each. During an authorized failure test, check both new connection behavior and the special cases that must stop instead of changing their exit path.
\nNetgate — Policy routing. Reviewed October 15, 2026.
", "content_text": "A gateway on a broad pass rule can send traffic away from routes that should remain local.\nSource facts\nIn pfSense, selecting a gateway or gateway group on a firewall rule policy-routes matching traffic through that selection. Netgate states that traffic intended for other local interfaces, VPNs, MPLS, or normal routing-table decisions must bypass policy routing. The documented method places a matching rule without a selected gateway above the broader gateway-bearing rule. Rule order matters because the first match is used. Netgate also documents additional handling when traffic must stop rather than fall through to another route after a selected gateway fails.\nSource: Netgate — Policy routing.\nApplicability\nThis concerns pfSense Multi-WAN rules on the relevant ingress interface. The actual destinations and route exceptions must come from the approved network design rather than a copied example address list.\nDSE recommendation\nDSE recommends building an explicit exception list for internal services, remote VPN networks, and other destinations that should follow the routing table. Review that list before changing a default pass rule to use a WAN group. Keep the exception rule immediately understandable and document why each destination belongs there. Decide separately which traffic may fail over and which must fail closed. Preserve the previous rule order for rollback, and coordinate testing with owners of remote management and site-to-site applications.\nVerification\nTest an approved local service, a VPN destination, and an internet destination from the same client. Confirm the intended path for each. During an authorized failure test, check both new connection behavior and the special cases that must stop instead of changing their exit path.\nOfficial reference\nNetgate — Policy routing. Reviewed October 15, 2026.", "content_markdown": "A gateway on a broad pass rule can send traffic away from routes that should remain local.\n\n## Source facts\n\nIn pfSense, selecting a gateway or gateway group on a firewall rule policy-routes matching traffic through that selection. Netgate states that traffic intended for other local interfaces, VPNs, MPLS, or normal routing-table decisions must bypass policy routing. The documented method places a matching rule without a selected gateway above the broader gateway-bearing rule. Rule order matters because the first match is used. Netgate also documents additional handling when traffic must stop rather than fall through to another route after a selected gateway fails.\n\nSource: [Netgate — Policy routing](https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html).\n\n## Applicability\n\nThis concerns pfSense Multi-WAN rules on the relevant ingress interface. The actual destinations and route exceptions must come from the approved network design rather than a copied example address list.\n\n## DSE recommendation\n\nDSE recommends building an explicit exception list for internal services, remote VPN networks, and other destinations that should follow the routing table. Review that list before changing a default pass rule to use a WAN group. Keep the exception rule immediately understandable and document why each destination belongs there. Decide separately which traffic may fail over and which must fail closed. Preserve the previous rule order for rollback, and coordinate testing with owners of remote management and site-to-site applications.\n\n## Verification\n\nTest an approved local service, a VPN destination, and an internet destination from the same client. Confirm the intended path for each. During an authorized failure test, check both new connection behavior and the special cases that must stop instead of changing their exit path.\n\n## Official reference\n\n[Netgate — Policy routing](https://docs.netgate.com/pfsense/en/latest/multiwan/policy-route.html). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/pfsense-state-table-nat-address-direction-diagnostics/", "slug": "pfsense-state-table-nat-address-direction-diagnostics", "url": "https://update.dsesecurity.com/updates/pfsense-state-table-nat-address-direction-diagnostics/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/pfsense-state-table-nat-address-direction-diagnostics.md", "json": "https://update.dsesecurity.com/api/v1/posts/pfsense-state-table-nat-address-direction-diagnostics/" }, "title": "Read both NAT addresses and both directions in the pfSense state table", "summary": "The state table can distinguish a translated connection from one that has not received a reply.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:31+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 272, "potentially_affected": "This concerns Diagnostics > States in pfSense. State entries describe traffic observed by the firewall; they do not alone prove where a packet was lost or why a remote application failed.", "dse_recommendation": "DSE recommends recording the expected client, destination, port, and NAT translation before changing rules.", "primary_source": { "name": "Netgate — Viewing firewall states", "url": "https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html", "published_on": null, "authority": "docs.netgate.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "The state table can distinguish a translated connection from one that has not received a reply.
\nNetgate’s state-table guide explains that pfSense displays original and translated addresses when NAT applies. The State column has two values separated by a colon, representing the source and destination sides. ESTABLISHED:ESTABLISHED describes established two-way TCP tracking, while SYN_SENT:CLOSED indicates a SYN without a response observed from the far side. For connectionless traffic, SINGLE:NO_TRAFFIC similarly indicates no matching response observed. The GUI can filter entries by a simple text expression, and an IP or subnet search also exposes a state-removal action.
\nSource: Netgate — Viewing firewall states.
\nThis concerns Diagnostics > States in pfSense. State entries describe traffic observed by the firewall; they do not alone prove where a packet was lost or why a remote application failed.
\nDSE recommends recording the expected client, destination, port, and NAT translation before changing rules. Use a narrow filter to inspect the relevant connection and compare both sides of the entry. Preserve a safe diagnostic snapshot with sensitive addresses handled appropriately. Distinguish a missing response from an application error after establishment. Treat the state-removal control as a separate disruptive action requiring a defined target and purpose, not a routine step for viewing a connection. Correlate uncertain results with approved packet captures or endpoint evidence.
\nGenerate one approved test connection and inspect its original and translated addresses. Compare a successful exchange with an intentionally unavailable test destination. Confirm the filter matches the expected entries and avoid removing unrelated states while collecting evidence.
\nNetgate — Viewing firewall states. Reviewed October 15, 2026.
", "content_text": "The state table can distinguish a translated connection from one that has not received a reply.\nSource facts\nNetgate’s state-table guide explains that pfSense displays original and translated addresses when NAT applies. The State column has two values separated by a colon, representing the source and destination sides. ESTABLISHED:ESTABLISHED describes established two-way TCP tracking, while SYN_SENT:CLOSED indicates a SYN without a response observed from the far side. For connectionless traffic, SINGLE:NO_TRAFFIC similarly indicates no matching response observed. The GUI can filter entries by a simple text expression, and an IP or subnet search also exposes a state-removal action.\nSource: Netgate — Viewing firewall states.\nApplicability\nThis concerns Diagnostics > States in pfSense. State entries describe traffic observed by the firewall; they do not alone prove where a packet was lost or why a remote application failed.\nDSE recommendation\nDSE recommends recording the expected client, destination, port, and NAT translation before changing rules. Use a narrow filter to inspect the relevant connection and compare both sides of the entry. Preserve a safe diagnostic snapshot with sensitive addresses handled appropriately. Distinguish a missing response from an application error after establishment. Treat the state-removal control as a separate disruptive action requiring a defined target and purpose, not a routine step for viewing a connection. Correlate uncertain results with approved packet captures or endpoint evidence.\nVerification\nGenerate one approved test connection and inspect its original and translated addresses. Compare a successful exchange with an intentionally unavailable test destination. Confirm the filter matches the expected entries and avoid removing unrelated states while collecting evidence.\nOfficial reference\nNetgate — Viewing firewall states. Reviewed October 15, 2026.", "content_markdown": "The state table can distinguish a translated connection from one that has not received a reply.\n\n## Source facts\n\nNetgate’s state-table guide explains that pfSense displays original and translated addresses when NAT applies. The State column has two values separated by a colon, representing the source and destination sides. ESTABLISHED:ESTABLISHED describes established two-way TCP tracking, while SYN_SENT:CLOSED indicates a SYN without a response observed from the far side. For connectionless traffic, SINGLE:NO_TRAFFIC similarly indicates no matching response observed. The GUI can filter entries by a simple text expression, and an IP or subnet search also exposes a state-removal action.\n\nSource: [Netgate — Viewing firewall states](https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html).\n\n## Applicability\n\nThis concerns Diagnostics > States in pfSense. State entries describe traffic observed by the firewall; they do not alone prove where a packet was lost or why a remote application failed.\n\n## DSE recommendation\n\nDSE recommends recording the expected client, destination, port, and NAT translation before changing rules. Use a narrow filter to inspect the relevant connection and compare both sides of the entry. Preserve a safe diagnostic snapshot with sensitive addresses handled appropriately. Distinguish a missing response from an application error after establishment. Treat the state-removal control as a separate disruptive action requiring a defined target and purpose, not a routine step for viewing a connection. Correlate uncertain results with approved packet captures or endpoint evidence.\n\n## Verification\n\nGenerate one approved test connection and inspect its original and translated addresses. Compare a successful exchange with an intentionally unavailable test destination. Confirm the filter matches the expected entries and avoid removing unrelated states while collecting evidence.\n\n## Official reference\n\n[Netgate — Viewing firewall states](https://docs.netgate.com/pfsense/en/latest/monitoring/status/firewall-states-gui.html). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/cloudflare-access-authentication-versus-request-logs/", "slug": "cloudflare-access-authentication-versus-request-logs", "url": "https://update.dsesecurity.com/updates/cloudflare-access-authentication-versus-request-logs/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cloudflare-access-authentication-versus-request-logs.md", "json": "https://update.dsesecurity.com/api/v1/posts/cloudflare-access-authentication-versus-request-logs/" }, "title": "Separate Access authentication evidence from HTTP activity evidence", "summary": "A successful login record does not list every action taken inside an application.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:27+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 260, "potentially_affected": "This concerns evidence available from Cloudflare Access and associated request logging. Application database changes, browser-only interactions, and business approvals may require separate application audit records.", "dse_recommendation": "DSE recommends writing the investigation question before choosing a log source.", "primary_source": { "name": "Cloudflare — Access logs", "url": "https://developers.cloudflare.com/cloudflare-one/insights/logs/dashboard-logs/access-authentication-logs/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A successful login record does not list every action taken inside an application.
\nCloudflare Access distinguishes authentication audit logs from per-request audit logs. Authentication logs describe login attempts and their outcomes; they do not capture the user’s actions during a self-hosted or SaaS application session. Per-request records can describe HTTP requests to protected paths, but interactions entirely within the browser produce no new server request to record. The documentation also separates identity-based and non-identity authentication logs, with different retrieval methods. Detailed HTTP logging and export features have their own availability requirements.
\nSource: Cloudflare — Access logs.
\nThis concerns evidence available from Cloudflare Access and associated request logging. Application database changes, browser-only interactions, and business approvals may require separate application audit records.
\nDSE recommends writing the investigation question before choosing a log source. For “who signed in,” preserve the authentication decision and application identifier. For “what was requested,” review the available request dataset and correlate timestamps and request identifiers. For “what changed,” obtain the application’s own audit trail. Document plan, retention, and export constraints before an incident, and protect any exported user or IP information. Do not describe a login-only export as a complete record of a user’s application activity.
\nWith a controlled test account, sign in and perform an approved server-backed action plus a browser-only interaction. Compare the authentication, request, and application records. Document expected gaps and confirm that the evidence collection procedure can retrieve the relevant period without assuming all events share one dashboard.
\nCloudflare — Access logs. Reviewed October 15, 2026.
", "content_text": "A successful login record does not list every action taken inside an application.\nSource facts\nCloudflare Access distinguishes authentication audit logs from per-request audit logs. Authentication logs describe login attempts and their outcomes; they do not capture the user’s actions during a self-hosted or SaaS application session. Per-request records can describe HTTP requests to protected paths, but interactions entirely within the browser produce no new server request to record. The documentation also separates identity-based and non-identity authentication logs, with different retrieval methods. Detailed HTTP logging and export features have their own availability requirements.\nSource: Cloudflare — Access logs.\nApplicability\nThis concerns evidence available from Cloudflare Access and associated request logging. Application database changes, browser-only interactions, and business approvals may require separate application audit records.\nDSE recommendation\nDSE recommends writing the investigation question before choosing a log source. For “who signed in,” preserve the authentication decision and application identifier. For “what was requested,” review the available request dataset and correlate timestamps and request identifiers. For “what changed,” obtain the application’s own audit trail. Document plan, retention, and export constraints before an incident, and protect any exported user or IP information. Do not describe a login-only export as a complete record of a user’s application activity.\nVerification\nWith a controlled test account, sign in and perform an approved server-backed action plus a browser-only interaction. Compare the authentication, request, and application records. Document expected gaps and confirm that the evidence collection procedure can retrieve the relevant period without assuming all events share one dashboard.\nOfficial reference\nCloudflare — Access logs. Reviewed October 15, 2026.", "content_markdown": "A successful login record does not list every action taken inside an application.\n\n## Source facts\n\nCloudflare Access distinguishes authentication audit logs from per-request audit logs. Authentication logs describe login attempts and their outcomes; they do not capture the user’s actions during a self-hosted or SaaS application session. Per-request records can describe HTTP requests to protected paths, but interactions entirely within the browser produce no new server request to record. The documentation also separates identity-based and non-identity authentication logs, with different retrieval methods. Detailed HTTP logging and export features have their own availability requirements.\n\nSource: [Cloudflare — Access logs](https://developers.cloudflare.com/cloudflare-one/insights/logs/dashboard-logs/access-authentication-logs/).\n\n## Applicability\n\nThis concerns evidence available from Cloudflare Access and associated request logging. Application database changes, browser-only interactions, and business approvals may require separate application audit records.\n\n## DSE recommendation\n\nDSE recommends writing the investigation question before choosing a log source. For “who signed in,” preserve the authentication decision and application identifier. For “what was requested,” review the available request dataset and correlate timestamps and request identifiers. For “what changed,” obtain the application’s own audit trail. Document plan, retention, and export constraints before an incident, and protect any exported user or IP information. Do not describe a login-only export as a complete record of a user’s application activity.\n\n## Verification\n\nWith a controlled test account, sign in and perform an approved server-backed action plus a browser-only interaction. Compare the authentication, request, and application records. Document expected gaps and confirm that the evidence collection procedure can retrieve the relevant period without assuming all events share one dashboard.\n\n## Official reference\n\n[Cloudflare — Access logs](https://developers.cloudflare.com/cloudflare-one/insights/logs/dashboard-logs/access-authentication-logs/). Reviewed October 15, 2026." }, { "id": "https://update.dsesecurity.com/updates/cloudflare-access-jwt-audience-rotating-key-validation/", "slug": "cloudflare-access-jwt-audience-rotating-key-validation", "url": "https://update.dsesecurity.com/updates/cloudflare-access-jwt-audience-rotating-key-validation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/cloudflare-access-jwt-audience-rotating-key-validation.md", "json": "https://update.dsesecurity.com/api/v1/posts/cloudflare-access-jwt-audience-rotating-key-validation/" }, "title": "Validate the Access audience and rotating signing keys at a Cloudflare-protected origin", "summary": "A forwarded identity header becomes trustworthy only after the intended token is verified.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "cyber-defense", "label": "Cyber defense", "alt": "Layered glass and metal cyber-defense structure with controlled blue and gold signal paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/cyber-defense-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "cybersecurity", "name": "Cybersecurity", "url": "https://update.dsesecurity.com/topic/cybersecurity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-15T13:33:25+00:00", "modified_at": "2026-10-15T13:36:17+00:00", "reviewed_on": "2026-10-15", "reading_minutes": 2, "word_count": 267, "potentially_affected": "This covers origins and Workers receiving Cloudflare Access tokens. It does not replace application-level authorization or independently establish that every route to the origin passes through Access.", "dse_recommendation": "DSE recommends placing token validation in the request path before privileged application work occurs.", "primary_source": { "name": "Cloudflare — Validate JWTs", "url": "https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/", "published_on": null, "authority": "developers.cloudflare.com" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A forwarded identity header becomes trustworthy only after the intended token is verified.
\nCloudflare sends an Access application token to the origin in the Cf-Access-Jwt-Assertion header. The documentation recommends validating this header because the browser authorization cookie is not guaranteed to be present. Signing keys belong to the account and rotate; verification should select the appropriate key using the token’s key identifier instead of hard-coding one public key. The application’s AUD value identifies which application a token is valid for. Cloudflare’s programmatic examples verify the expected issuer and application audience as well as the signature.
\nSource: Cloudflare — Validate JWTs.
\nThis covers origins and Workers receiving Cloudflare Access tokens. It does not replace application-level authorization or independently establish that every route to the origin passes through Access.
\nDSE recommends placing token validation in the request path before privileged application work occurs. Configure the expected team issuer and application audience explicitly, and use a maintained verification library with support for remote key sets. Review the origin’s direct reachability and reject missing or invalid tokens on protected routes. Design key retrieval and caching to handle rotation without accepting arbitrary issuers. Log a safe reason code for rejection while excluding raw tokens and sensitive claim values from ordinary diagnostic output.
\nIn a test deployment, try a valid intended token, a missing token, and a valid token issued for another application. Confirm rejection of the wrong audience. Exercise key-refresh behavior using the vendor’s documented test options and verify that signature validation remains enforced throughout.
\nCloudflare — Validate JWTs. Reviewed October 15, 2026.
", "content_text": "A forwarded identity header becomes trustworthy only after the intended token is verified.\nSource facts\nCloudflare sends an Access application token to the origin in the Cf-Access-Jwt-Assertion header. The documentation recommends validating this header because the browser authorization cookie is not guaranteed to be present. Signing keys belong to the account and rotate; verification should select the appropriate key using the token’s key identifier instead of hard-coding one public key. The application’s AUD value identifies which application a token is valid for. Cloudflare’s programmatic examples verify the expected issuer and application audience as well as the signature.\nSource: Cloudflare — Validate JWTs.\nApplicability\nThis covers origins and Workers receiving Cloudflare Access tokens. It does not replace application-level authorization or independently establish that every route to the origin passes through Access.\nDSE recommendation\nDSE recommends placing token validation in the request path before privileged application work occurs. Configure the expected team issuer and application audience explicitly, and use a maintained verification library with support for remote key sets. Review the origin’s direct reachability and reject missing or invalid tokens on protected routes. Design key retrieval and caching to handle rotation without accepting arbitrary issuers. Log a safe reason code for rejection while excluding raw tokens and sensitive claim values from ordinary diagnostic output.\nVerification\nIn a test deployment, try a valid intended token, a missing token, and a valid token issued for another application. Confirm rejection of the wrong audience. Exercise key-refresh behavior using the vendor’s documented test options and verify that signature validation remains enforced throughout.\nOfficial reference\nCloudflare — Validate JWTs. Reviewed October 15, 2026.", "content_markdown": "A forwarded identity header becomes trustworthy only after the intended token is verified.\n\n## Source facts\n\nCloudflare sends an Access application token to the origin in the Cf-Access-Jwt-Assertion header. The documentation recommends validating this header because the browser authorization cookie is not guaranteed to be present. Signing keys belong to the account and rotate; verification should select the appropriate key using the token’s key identifier instead of hard-coding one public key. The application’s AUD value identifies which application a token is valid for. Cloudflare’s programmatic examples verify the expected issuer and application audience as well as the signature.\n\nSource: [Cloudflare — Validate JWTs](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/).\n\n## Applicability\n\nThis covers origins and Workers receiving Cloudflare Access tokens. It does not replace application-level authorization or independently establish that every route to the origin passes through Access.\n\n## DSE recommendation\n\nDSE recommends placing token validation in the request path before privileged application work occurs. Configure the expected team issuer and application audience explicitly, and use a maintained verification library with support for remote key sets. Review the origin’s direct reachability and reject missing or invalid tokens on protected routes. Design key retrieval and caching to handle rotation without accepting arbitrary issuers. Log a safe reason code for rejection while excluding raw tokens and sensitive claim values from ordinary diagnostic output.\n\n## Verification\n\nIn a test deployment, try a valid intended token, a missing token, and a valid token issued for another application. Confirm rejection of the wrong audience. Exercise key-refresh behavior using the vendor’s documented test options and verify that signature validation remains enforced throughout.\n\n## Official reference\n\n[Cloudflare — Validate JWTs](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/). Reviewed October 15, 2026." } ] }