### Problem to solve Before DAST scans a website, the target website is checked to verify that it is up and running. This is to ensure that the ZAP scan is able to spider all URLs on the website, and helps ensure results are deterministic. Unfortunately, some websites have target URLs which cause problems with the check. These include: - Websites that take longer than 5 seconds to load - Websites that have lots of redirects - Websites that return status codes in the range 400-500 ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) * [Sam (Security Analyst)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sam-security-analyst) ### Implementation plan - [x] DAST should continue to scan when the website returns a 400 series error. The error is a client error, which indicates that the server is up and running. - [x] DAST should provide an environment variable, `DAST_SKIP_TARGET_CHECK`. When set to `true`, the target check made by DAST should be skipped entirely. `DAST_SKIP_TARGET_CHECK` should be `false` by default. - [x] More information should be emitted to explain why the website check failed. See https://gitlab.com/gitlab-org/gitlab/-/issues/237842 for a suggestion on how this might look. See also https://gitlab.com/gitlab-org/gitlab/-/issues/245255 for an explanation on what information would be useful. - [x] If the site check fails, the job log should include a message to explain to the user what options they have, for example, "Set the variable DAST_SKIP_TARGET_CHECK to false to prevent this check". ### Documentation Please document the new environment variable in the DAST documentation. ### Availability & Testing <!-- This section needs to be retained and filled in during the workflow planning breakdown phase of this feature proposal, if not earlier. What risks does this change pose to our availability? How might it affect the quality of the product? What additional test coverage or changes to tests will be needed? Will it require cross-browser testing? Please list the test areas (unit, integration and end-to-end) that needs to be added or updated to ensure that this feature will work as intended. Please use the list below as guidance. * Unit test changes * Integration test changes * End-to-end test change See the test engineering planning process and reach out to your counterpart Software Engineer in Test for assistance: https://about.gitlab.com/handbook/engineering/quality/test-engineering/#test-planning --> ### What is the type of buyer? [Gold/Ultimate](https://about.gitlab.com/handbook/product/pricing/#four-tiers)