Best practices in regards to FOD integration into SDLC


Thank you for taking the time to read my query.

As a new FOD customer, we are looking into how is best to integrate FOD into our SDLC and was wondering if you could provide some insight.

At the moment we are looking at doing a scan per pull request, however, we are unsure how best to do so.

Based on our findings, we would have to create a new development release for every pull request. However, unless we manually do so, it appears that the only way to automate this via our CI is to utilise your API via a custom script.

Furthermore, there is the concern of how much time each release will take to finish scanning. Does the initial scan for a new release take longer than a subsequent scan for one that already exists?

Lastly, if a PR fails as a result of not meeting our FOD policy, would you expect a security lead/project manager to triage these findings before the developer responsible for the PR branch attempts to fix anything? Also since we know who created the PR, would it be possible to automate the vulnerability assignment process?

Please feel free to suggest otherwise.


  • Hi Andrew,

    Thank you for becoming an FOD customer!

    Regarding scanning every pull request (PR): Whether or not you need to create a separate development release for every PR is dependent on the question of whether or not you need to keep track of multiple PRs in parallel. If you are on a small team and can process PRs one at a time, you could simply re-use the same development release for each scan. Uploading a scan request for a new PR would result in overwriting the prior data, while keeping prior auditing work, of course.

    If you're on a larger team and need to keep track of the baseline and several on-going PRs simultaneously, then this won't be practical. In that case, you will need to create separate development releases in FoD; and you're right, FoD API calls would be the way to go then. This can be quite easily done in a script using cURL. Please be aware that for one application, only one scan can be running at the same time. When scan requests come in while a scan is running, these can be queued.

    Regarding the scan time: first of all, this is highly dependent on whether manual false positive review is taking place. Our most popular offering is the "static subscription", which includes a manual false positive review on the first scan of a new app, but has a fully automatic process on subsequent scans, including new development releases. For these fully automatic scans, typical scan time is less than 15 minutes and even less for microservices.

    On the topic of whether or not security leads to triage before sending results to developers: Our experience is that guidance in the portal is sufficient for developers to process directly, especially when scanning on an ongoing basis.

    Finally, on the vulnerability assignment question: FOD can't do this out of the box, because it's not aware of Git PRs as such. If could certainly be achieved by calls to the FOD API from the CI server. If you are using GitHub: we are currently working on deepening our GitHub integration; if you contact your FOD TAM with your specific requirements, we can take them into account in these developments.

    With kind regards,

    Frans van Buul







  • Thank you for getting back to me, that's definitely cleared up those areas for us.

    Just another question if I can.

    In regards to resolving/closing vulnerabilities, is this done automatically when a subsequent fix scan finds that it's no longer an issue? or must this be done manually and suppressed?



  • Hi Andrew,

    Yes, this is done automatically. If an issue is no longer detected during the latest scan, it is automatically removed from the list of issues for the application.