As an MVC, this feature would introduce on-demand scans by adding a page where a user can specify the target URL and start a scan. The scan would use the passive mode to scan the site for 60 seconds. Once the user starts the scan, we can redirect them to the pipeline page to show the job running. These jobs will always be associated with the default or master branch and the results can be seen in the project dashboard or the pipeline dashboard.
Further details
Empty status
New scan nothing filled in
New scan, url filled
+ side bar +illustration + two buttons
+ new form, url not filed + cancel button goes back to empty page
+ valide url filled in and button enabled
Implementation Steps
Addition of Asynchronous Scans in the Security & Compliance menue
jobs will always be associated with the default or master branch
My assumption is that users will never have the option to select a branch here. Or do we want to let them choose between the default branch and the master branch in the case where masterisn't the default branch? Otherwise, I suppose that we don't absolutely need a dropdown there, it could be a simple info text.
What should the frontend regex check for?
My understanding here is that users will be able to scan live apps by entering their URL. Do we want to make sure that they are not trying to scan an app that they do not own by comparing the typed URL with some other setting? Or do we simply check that the input is a valid URL?
Is the Cancel button's color variant right?
In the designs, the Cancel button uses the secondary success variant (outlined green).
However, we usually use the tertiary variant for cancel buttons, here's the Cancel button in the New issue form for example:
For the MVC, they will not be able to select which branch the scan is associated with, but that might change in the future, as we iterate on the functionality. For the MVC, I don't really care if it is a disabled dropdown or text stating that it will be associated with the default/master branch. Either way, we will be able to update it in a future iteration to allow the user to select their branch.
I think that the validation you posted makes sense. We don't want to do any domain name restrictions right now, since it could be an IP, FQDN, or just a single word in an intranet type situation.
I'll leave that with @cam.x. I think that we should align completely with the design standards being used in other places, but I am not that familiar with all the standards yet.
@pgascouvaillancourt Sorry for that, too much copy/paste today: should be this one. I haven't read the technical doc yet. Possible update for the text after the doc is ready.
This is something I found while looking at the overall flow of DAST On-demand scans and somehow related:
It looks like the redirect (step .4 in the outline) should bring the user to the freshly triggered pipeline's security tab (and include a message that the report is not yet ready).
Currently the security tab is only visible once the pipeline has finished. Only then can it be linked to, if the pipeline is still in progress and you navigate to /pipelines/{id}/security it will redirect to pipelines/{id}.
I think there will be work for both backend and frontend to have the tab visible and display a placeholder but maybe that is a separate issue?
Update: I just came across #218587 (closed) and I think this point belongs be there.
FYI, I created 4 sub-issues including one for the backend with a minimal implementation plan: #218685 (closed)
Please let me know if you can think of any challenge that we should take into consideration before starting the implementation. Could you also take a look at the proposed GraphQL mutation to make sure it makes sense?
i spoke with @avielle this morning and what you've put looks good but i just wanted to make a couple of suggestions about the shape of the mutation and wondered if you could let me know if these make sense to you.
here's what i propose we work towards:
mutation{runDastScan(input:{projectPath:ID!,targetUrl:String!,branch:String!,scanType:DastScanTypeEnum!}){pipelineUrl}}# where DastScanTypeEnum has a single value: passive
the changes are as follows:
it looked like input was missing.
it looked like there were mutations in the backend using a mix of project id and project path but project path looked like it was slightly more prevalent. does this work for you?
i added scanType enum which has a single constructor (passive). does this add a lot of overhead for you?
it looked like there were mutations in the backend using a mix of project id and project path but project path looked like it was slightly more prevalent. does this work for you?
Absolutely!
i added scanType enum which has a single constructor (passive). does this add a lot of overhead for you?
That's fine! I like that we're including this field already so that we're ready for adding more possible values in future iterations.