<html><body bgcolor="#FFFFFF"><div>The only problem I see is that the FPR file is signed so nobody modifies it<br><br></div><div>A.</div><div><br>El 30/07/2011, a las 15:39, Dinis Cruz &lt;<a href="mailto:dinis@ddplus.net">dinis@ddplus.net</a>&gt; escribió:<br>
<br></div><div></div><blockquote type="cite"><div>Following the multiple blog entries prosted about <a href="http://o2platform.wordpress.com/category/tools/fortify/">O2&#39;s support for Fortify&#39;s FVDL</a>, (<i><span class="Apple-style-span" style="font-style: normal; ">sent to me by an O2 user) here </span></i>is a description of a use-case that O2 should support:<br>


<br><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>I would shoot for the ability to disposition large *.fpr/*.fvdl files. <br></i><i><br></i><i>Here is a typical workflow: <br>


</i><i><br></i></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">


<i>1.      Scan is run code base generating an *.fpr file</i></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>2.      Code Reviews receive the file but because it is too large it cannot be opened by Fortify’s tool.</i></blockquote>


<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>3.      Code reviewer uses O2 to open file and disposition or suppress issues by Category (XSS, SQL Injection, Path Tampering, etc.)</i></blockquote>


<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>4.      Code Reviewer then saves dispositions to *.fpr file.</i></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">


<i>5.      The *.fpr is saved and on subsequent scan of the same application.  The new.fpr file is merged with the old.fpr file.</i></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">


<i>6.      The code reviewer works on the merged.fpr to disposition items.</i></blockquote><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><i>7.      Wash, rinse, repeat.</i></blockquote>


<blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;"><i><br><span class="Apple-style-span" style="font-style: normal; "><i>The data needs to be stored in the *.fpr file because most code assessment processes relies on merging the old fpr with the new *.fpr/*.fvdl on subsequent rereviews.</i></span></i></blockquote>


</blockquote><div><i><br></i></div><div><i><br></i></div><div>Next step(s) is to write a script(s) to implement this workflow, and try to figure the best GUIs to enable it.</div><div><br></div><div>Dinis Cruz</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>Owasp-o2-platform mailing list</span><br><span><a href="mailto:Owasp-o2-platform@lists.owasp.org">Owasp-o2-platform@lists.owasp.org</a></span><br>
<span><a href="https://lists.owasp.org/mailman/listinfo/owasp-o2-platform">https://lists.owasp.org/mailman/listinfo/owasp-o2-platform</a></span><br></div></blockquote></body></html>