9. Application security
Recommendations for protecting your application against bots
9.1 Yandex SmartCaptcha is used
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.
- In the management console
, select the folder. - Select Yandex SmartCaptcha.
- Make sure at least one CAPTCHA is created for your application.
Guides and solutions to use:
Guide on creating a CAPTCHA in Yandex SmartCaptcha.
Recommendations 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)
9.2 Docker image scans on push 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.
- In the management console
, select the folder that the registry with Docker images belongs to. - Select the appropriate registry in Container Registry.
- Go to the Vulnerability scanner tab and click Edit settings.
- Make sure Docker image scans on push are enabled.
Guides and solutions to use:
Guide on scanning Docker images on push.
9.3 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.
- In the management console
, select the folder that the registry with Docker images belongs to. - Select the appropriate registry in Container Registry.
- Go to the Vulnerability scanner tab and click Edit settings.
- Make sure that scheduled Docker image scans are enabled with a frequency of at least once a week.
Guides and solutions to use:
Guide on scheduled scanning of Docker images.
9.4 Containerized images used in production environments have the last scan date a 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.
Run the command below to search for containerized images with the last scan date a week ago or less:
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
9.5 Software artifacts are built using attestations
Attestations are used when building software artifacts to 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
Make sure that artifact attestation is performed while building an application.
Guides and solutions to use:
Gitlab guide for software artifact attestation
9.6 Ensuring artifact integrity
Signing artifacts enhances security to ensure your software validity, integrity, reliability, and compliance with the requirements.
Make sure that artifacts are signed while building an application.
Guides and solutions to use:
You can sign artifacts within a pipeline using Cosign
9.7 Artifacts are verified 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.
Make sure that artifacts are verified while building an application.
Guides and solutions to use:
Guide on setting up the artifact signature.
9.8 Protected templates of a secure pipeline are used
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 . Available for all license types. - Using the
Compliance framework and pipeline
mechanism that you can run in any group project. Available for theUltimate
license. - Copying pipeline sections to
.gitlab-ci.yml
files in your projects.