Welcome to mirror list, hosted at ThFree Co, Russian Federation.

202211220001_15_06.yml « whats_new « data - gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
blob: e966305abf0f28d2c4d866befd38bec07d51da12 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
- name: "Group and subgroup-level scan result policies"
  description: |
    GitLab now supports managing scan result policies at both the group and subgroup levels.
    These policies automatically flow down and apply to all projects inside the group. This
    makes it considerably easier to enforce these policies uniformly for large organizations
    that have large numbers of projects. To get started, have a group or subgroup Owner link
    an associated security policy project on the **Security & Compliance > Policies** page.
  stage: Govern
  self-managed: true
  gitlab-com: true
  available_in: [Ultimate]
  documentation_link: 'https://docs.gitlab.com/ee/user/application_security/policies/scan-result-policies.html'
  image_url: 'https://img.youtube.com/vi/jfbNo5IE-2s/hqdefault.jpg'
  published_at: 2022-11-22
  release: 15.6
- name: "Git abuse rate limiting"
  description: |
    In GitLab 15.6, we're introducing [Git abuse rate limiting](https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html).
      Enable this feature to automatically notify administrators when a user downloads
      or clones more than a specified number of repositories in a group or any of its
      subgroups within a given time frame.

      You can also automatically ban users who exceed the rate limit.
      Banned users cannot access the main group or any of its non-public subgroups.
      Access to unrelated groups is unaffected. Bans are permanent by default, but
      group administrators can always unban a banned user.
  stage: anti-abuse
  self-managed: true
  gitlab-com: false
  available_in: [Ultimate]
  documentation_link: 'https://docs.gitlab.com/ee/user/group/reporting/git_abuse_rate_limit.html'
  image_url: 'https://about.gitlab.com/images/15_6/git-abuse-rate-limiting.png'
  published_at: 2022-11-22
  release: 15.6
- name: "DAST API analyzer for on-demand DAST API scans"
  description: |
    With GitLab 15.6, the DAST API analyzer is now being used for GitLab on-demand DAST API scans.
    In previous versions of GitLab, the analyzer used in these on-demand scans was our legacy DAST
    analyzer. Our internal benchmarking shows that our DAST API analyzer finds more vulnerabilities,
    with a lower false-positive rate than our legacy analyzer. The DAST API analyzer also introduces
    new functionality such as GraphQL scans, support for authentication tokens that expire, scans using
    Postman collections, and scans using HAR files. With the switch to the DAST API analyzer, some of
    that functionality is already available in the on-demand site profile.

    In addition to using an OpenAPI specification in the site profile to define an API test, you can now
    use a Postman collection or HAR file to make sure that your test gets the API coverage that you expect.
    Also, we've added basic authentication as an option for on-demand API scans, adding to the previous
    functionality of using token authentication in authorization headers.

    Next, we will be working next on adding GraphQL support for on-demand API scans. Look for more improvements
    over the next few releases as we incorporate more of the advanced functionality of the DAST API analyzer.
  stage: secure
  self-managed: true
  gitlab-com: true
  available_in: [Ultimate]
  documentation_link: 'https://docs.gitlab.com/ee/user/application_security/dast_api/'
  image_url: 'https://about.gitlab.com/images/15_6/on_demand_api_security.png'
  published_at: 2022-11-22
  release: 15.6
- name: "Support for special characters in CI/CD variables"
  description: |
    Previously, it was difficult to use the $ character in a CI/CD variable because $ normally signifies the
    start of another variable. GitLab would interpret it as a variable and try to expand it. In this release,
    we are introducing the variable: expand: keyword which will allow you to mark a variable as “raw”. A raw
    variable can contain any special characters and is not expanded when passed to the GitLab runner.
  stage: verify
  self-managed: true
  gitlab-com: true
  available_in: [Free, Premium, Ultimate]
  documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#variablesexpand'
  image_url: 'https://about.gitlab.com/images/15_6/special_character_support.png'
  published_at: 2022-11-22
  release: 15.6
- name: "CI/CD variable support in rules:exists configuration"
  description: |
    The more complex your .gitlab-ci.yml configuration is, the more difficult it is to maintain and scale. By
    adding support for CI/CD variables with the rules: exists keyword, you can now use variables for paths
    or filenames. Having a single source of truth by storing frequently used values in variables ensures
    consistent behavior and makes your configuration easier to manage.
  stage: verify
  self-managed: true
  gitlab-com: true
  available_in: [Free, Premium, Ultimate]
  documentation_link: 'https://docs.gitlab.com/ee/ci/yaml/#rulesexists'
  image_url: 'https://about.gitlab.com/images/15_6/variable_support_rule_exists.png'
  published_at: 2022-11-22
  release: 15.6