8. Application security

Recommendations for protecting your application against botsRecommendations for protecting your application against bots

8.1 Use Yandex SmartCaptcha8.1 Use Yandex SmartCaptcha

To mitigate the risks associated with automated attacks on applications, we recommend using Yandex SmartCaptcha. The service checks user requests with its ML algorithms and only shows challenges to those users whose requests it considers suspicious. You do not have to place the "I’m not a robot" button on the page.

Guides and solutions to use:

Guide on creating a CAPTCHA in Yandex SmartCaptcha.

Recommendations on building a secure pipelineRecommendations on building a secure pipeline

Yandex Cloud allows customers to achieve compliance of software they develop at all Supply-chain Levels for Software Artifacts (SLSA), provided that they follow the guidelines given in this section. When using Yandex Managed Service for GitLab, a customer automatically achieves SLSA Level 2 compliance.

8.2 Implement scanning of Docker images when uploading them to Yandex Container Registry8.2 Implement scanning of Docker images when uploading them to Yandex Container Registry

Auto scans of Docker images on push are critical for early detection and elimination of vulnerabilities to ensure secure deployment of containers. Reports on completed scans provide a brief description of detected vulnerabilities and issues and help you set priorities and eliminate security risks in containerized applications.

Guides and solutions to use:

Guide on scanning Docker images on push.

8.3 Schedule regular scanning of Docker images stored in Container Registry8.3 Schedule regular scanning of Docker images stored in Container Registry

Scheduled scanning of Docker images is an automated process that checks containerized images for vulnerabilities and compliance with security standards. Such scans are regular and automatic to ensure the consistency of image checks for vulnerabilities and maintain a high security level in the long run. Reports on completed scans provide a brief description of detected vulnerabilities and issues and help you set priorities and eliminate security risks in containerized applications.

We recommend setting up a schedule for scans to be run at least once a week.

Guides and solutions to use:

Guide on scheduled scanning of Docker images.

8.4 Make sure containerized images used in production environments have the last scan date of one week ago or less8.4 Make sure containerized images used in production environments have the last scan date of one week ago or less

Checking Docker images used in production environments with the last scan date not older than a week ensures that you continuously monitor and update security measures, eliminating potential vulnerabilities that might have occurred since the last scan. This also helps you make sure you are not deploying containers with recently detected vulnerabilities and enhance the security level. You can automate this process by setting up a schedule in the Vulnerability scanner.

export ORG_ID=<organization_ID>
for CLOUD_ID in $(yc resource-manager cloud list --organization-id=${ORG_ID} --format=json | jq -r '.[].id');
do for FOLDER_ID in $(yc resource-manager folder list --cloud-id=$CLOUD_ID --format=json | jq -r '.[].id');
do for REGISTRY_ID in $(yc container registry list --folder-id $FOLDER_ID --format=json | jq -r '.[].id');
do for IMAGE_ID in $(yc container image list --registry-id $REGISTRY_ID --format=json | jq -r '.[].id';)
do LAST_SCAN_DATE=$(yc container image get-last-scan-result --image-id $IMAGE_ID --format=json 2>/dev/null | jq -r '.scanned_at');
[ ! -z "$LAST_SCAN_DATE" ] && [ $(date --date "$LAST_SCAN_DATE" +'%s') -lt $(date --date '7 days ago' +'%s') ] && echo "Regitry ID - $REGISTRY_ID, Image ID - $IMAGE_ID, Last scan date - $LAST_SCAN_DATE"
done;
done;
done;
done

8.5 Use attestations when building software artifacts8.5 Use attestations when building software artifacts

Attestations used when building software artifacts help ensure a secure and verifiable record of an artifact's origin, integrity, and SBOM compliance. This helps ensure the artifact reliability throughout its lifecycle. A software bill of materials (SBOM) is required to secure a supply chain, manage vulnerabilities, comply with requirements, assess risks, ensure transparency, and respond to incidents in an effective way.

With Managed Service for GitLab, attestations are easier to use, as the service has a feature for generating a provenance attestation. An SBOM can be generated using syft, a third-party software tool.

Guides and solutions to use:

Gitlab guide for software artifact attestation.

8.6 Ensure artifact integrity8.6 Ensure artifact integrity

Signing artifacts enhances security to ensure your software validity, integrity, reliability, and compliance with the requirements.

Guides and solutions to use:

To sign artifacts within a pipeline, you can use Cosign, a third-party command line utility for signing artifacts, images, and in-to-to attestations. Then you can upload these artifacts to Yandex Container Registry.

A special build of Cosign allows you to store the created digital signature key pair in Yandex Key Management Service, sign files and artifacts with the private key of the pair, and verify a digital signature using its public key.

For more information, see Signing and verifying Container Registry Docker images in Yandex Managed Service for Kubernetes.

8.7 Verify artifacts on deployment8.7 Verify artifacts on deployment

To ensure the reliability, security, and compatibility of applications in Managed Service for Kubernetes, a service for automatic scaling and deployment of applications, you need to minimize the risk of issues, vulnerabilities, and failures during your application deployment and runtime. To do this, use signatures and signature verification in Managed Service for Kubernetes with Cosign and Kyverno.

Guides and solutions to use:

Guide on setting up the artifact signature.

8.8 Use protected templates of a secure pipeline8.8 Use protected templates of a secure pipeline

When working with Managed Service for GitLab, make sure you use built-in GitLab security mechanisms to secure your pipeline. The following options of pipeline usage are available for your projects:

• Creating a pipeline in an individual project and connecting it to other projects using the include function. This option is available for all license types.
• Using the Compliance framework and pipeline mechanism that you can run in any group project. It is available for the Ultimate license.
• Copying pipeline sections to .gitlab-ci.yml files in your projects.

8.9 Use a Yandex Smart Web Security security profile8.9 Use a Yandex Smart Web Security security profile

Yandex Smart Web Security is a service for protection against DDoS attacks and bots at application level L7 of the OSI model. Smart Web Security connects to Yandex Application Load Balancer.

In a nutshell, the service checks the HTTP requests sent to the protected resource against the rules configured in the security profile. Depending on the results of the check, the requests are forwarded to the protected resource, blocked, or sent to Yandex SmartCaptcha for additional verification.

Guides and solutions to use:

Creating a security profile and connecting it to a virtual host of an L7 load balancer.

8.10 Use a web application firewall8.10 Use a web application firewall

To mitigate risks associated with web attacks, we recommend using the Yandex Smart Web Security web application firewall (WAF). A web application firewall analyzes HTTP requests to a web app according to pre-configured rules. Based on the analysis results, certain actions are applied to HTTP requests.

You can manage the web application firewall using a WAF profile that connects to a security profile in Smart Web Security as a separate rule.

Guides and solutions to use:

Creating a WAF profile and connecting it to a security profile in Smart Web Security.

8.11 Use Advanced Rate Limiter8.11 Use Advanced Rate Limiter

Advanced Rate Limiter (ARL) is a module used to monitor and limit web app loads. The module allows you to set a limit on the number of HTTP requests over a certain period of time. All requests above the limit will be blocked. You can set a single limit for all traffic or configure specific limits to segment requests by certain parameters. For the purposes of limits, you can count requests one by one or group them together based on specified characteristics.

You need to connect your ARL profile to the security profile in Smart Web Security.

Guides and solutions to use:

Creating an ARL profile and connecting it to a security profile in Smart Web Security.

8.12 Set up approval rules8.12 Set up approval rules

With Yandex Managed Service for GitLab, you can flexibly set up mandatory approval rules for adding code to the target project branch. This feature is an alternative to the GitLab Enterprise Edition’s Approval Rules tool and is available regardless of the GitLab version.

If a GitLab instance has the approval rules enabled, Managed Service for GitLab analyzes approvals from reviewers for compliance with the specified rules. If there are not enough approvals, a thread is created in a merge request that blocks it from being merged to the target branch. Editing the merge request creates or updates a comment in the thread with its current compliance status. Once all the required approvals are obtained, the thread is closed.

If you close a thread manually, it will be created again. If a merge request is approved regardless of the existing rules, users with the Maintainer role or higher will receive an email notification about the violated code approval workflow.

Guides and solutions to use:

Enabling approval rules in the GitLab instance