- Update group and project policy
- Disable `New framework` button when only
read compliance ability is enabled and admin compliance
ability is not

Changelog: added
EE: true

This removes an already enabled feature flag for secret push
protection feature.

Changelog: removed
EE: true

Changelog: fixed
EE: true

Updates the permissions to read project and group comment templates
to be for report level and above.

Changelog: changed
EE: true

#506775

* Chat GA was in 16.11, and a licensed seat was required as of 17.6
* Now we can remove the feature flags that were added so that specific
  groups and instances could require a seat before seats were required
* Closes https://gitlab.com/gitlab-org/gitlab/-/issues/457091
* Closes #457757

Changelog: other
EE: true

Prevents access to projects and groups to "Duo Workflow user". Because there is
currently no real "Duo Workflow user" (Duo Workflow uses user's
account), the only difference is that it uses a special token for
authenticating its requests (this token has "ai_workflows" scope).

If this token is used for authenticating a request and it attempts to
access a project or group which has Duo features disabled, it prevents
access to this resource.

#499798

Changelog: fixed
MR: !173015
EE: true

Add a new static role that defines Product Manager abilities

Add group policies for Planner role

Add project policies for Planner role

Add issue, epic and issuable policies

Changelog: added

Removes default enabled feature flag used to
rollout duo enterprise add on launch.

Changelog: other
EE: true

This API will allow users to request and update
a project's security settings, specifically
for pre_receive_secret_detection_enabled.
New documentation and testing covering this
change has been added. Note that only users
with Maintainer+ role can update the value
as this would turn on SPP for the project.
Users with developer+ role can view the
security settings.

Changelog: added
EE: true

When the Duo Code Review bot is added as a reviewer this will start a new review
the bots review status will get updated to `review_started` when it starts the review
to then `reviewed` when the review has been finished.
A new review can then be requested from the bot using the request a review feature.

Contributes to #482942

**Problem**

We use `Authz::CustomAbility.allowed?` to check custom abilities of the
user. But for each ability we trigger two database requests to fetch
the same project and namespace. That leads to N+1 problem.

**Solution**

1. Restructure `Authz::CustomAbility` to support caching.

The code below won't trigger unnecessary database queries for each
`allowed?` call.

```ruby
ability = Authz::CustomAbility.new(user, project)
ability.allowed?(:ability_1)
ability.allowed?(:ability_2)
```

2. Add caching level to the policy code

`Authz::CustomAbility` record will be memoized and have access to
permitted abilities to optimize the number of DB queries.

Changelog: performance
EE: true

Some features will be available for pro seats
while others only for enterprise seats

This service allows the correspondent GraphQL type
to parse the Terraform templates so GKE based runners
can be created

Changelog: added
EE: true

This restricts Duo Workflow access when duo_features_enabled
is set to false on project, group or instance level.
Changelog: changed
EE: true

* implement access to standard adherence report at project level

EE: true
Changelog: added

- ignore sast
- ignore duo-workflow
- ignore self-hosted-models

Revert sast changes from !168249 (diffs)

* required for compliance framework report

Changelog: added
EE: true

This adds restriction on duo workflow access to only
projects or groups having ultimate license
Changelog: added
EE: true

Checks if the correct permissions are set
and the given finding is resolvable with AI.

Co-authored-by: Nikola Milojevic <nmilojevic@gitlab.com>

Downgrade from developer+ to reporter+ permission
to read analytics dashboards.

EE: true
Changelog: changed

Add appropriate license check for Secret Push Protection policies.
Changelog: fixed
EE: true

This change adds a project setting that allows to grant repository
access to SPP project for the linked projects.

This is necessary because user may not have permission to the Security
Policy Project where the linked Pipeline execution policy configuration
is stored. In such case, the user is not able to run pipelines
in projects where the PEP is enabled.

Changelog: added
EE: true

Changelog: added
EE: true

* Move SaaS check from policies to User model
* Rename AI analytics rule condition to be more suited

Ai impact analytics will be available only when
duo enterprise add on is present after october.
A feature flag will be used to simulate a cutoff date, IOW
the check will only be executed when the flag gets turned on.

EE: true
Changelog: other

Add a new error message for job token case
Differenciate errors from user has no permissions and project is not in allowlist
Rename condition for better clarity
Update token_forbidden error message with suggested
Add more details on no permission error

Changelog: changed

We want to be able to see which projects are using "Secret Push
protection" on API level.

See
gitlab-com/gl-security/product-security/gib#111
for a use case

Changelog: changed

Add license check container_scanning_for_registry_available
to feature enable/disable button

Fix formatting

Changelog: fixed
EE: true

Alan (Maciej) Paruszewski authored 7 months ago and GitLab Release Tools Bot committed 7 months ago

Merge branch 'security-1160-restrict-access-for-security-policy-bot' into 'master'

See merge request gitlab-org/security/gitlab!4328

Changelog: security