Re: [SC-L] Security in open source components
Hi Christian, Thanks for the additional info I'll definitely be in touch with the author of this project. We are currently having a bit of a rethink about our approach so input from somebody that has tackled things from a different angle will be really useful. Cheers, Grant. On 10/28/2012 11:51 AM, Christian Heinrich wrote: > ... and I found https://github.com/jeremylong/DependencyCheck#readme today > (i.e. Sunday 28 October 2012) via GitHub. > > On Fri, Oct 26, 2012 at 10:34 AM, Christian Heinrich < > christian.heinr...@cmlh.id.au> wrote: > >> Grant, >> >> ... and >> http://www.scmagazine.com.au/News/320617,redhat-project-fights-java-vulnerabilities.aspx >> was published yesterday (25 Oct). >> >> On Mon, Oct 1, 2012 at 3:19 PM, Christian Heinrich >> wrote: >>> Grant, >>> >>> Below are the discussions related to Maven and the paper referenced: >>> 1. http://krvw.com/pipermail/sc-l/2012/002786.html >>> 2. http://krvw.com/pipermail/sc-l/2012/002788.html >>> >>> On Fri, Sep 28, 2012 at 9:10 AM, Grant Murphy >> wrote: I don't have the original mail but some time ago a thread on this list mentioned this article: >> http://www.sonatype.com/Products/Why-Sonatype/Reduce-Security-Risk/Security-Brief >> >> >> -- >> Regards, >> Christian Heinrich >> >> http://cmlh.id.au/contact >> > > > signature.asc Description: OpenPGP digital signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Security in open source components
... and I found https://github.com/jeremylong/DependencyCheck#readme today (i.e. Sunday 28 October 2012) via GitHub. On Fri, Oct 26, 2012 at 10:34 AM, Christian Heinrich < christian.heinr...@cmlh.id.au> wrote: > Grant, > > ... and > http://www.scmagazine.com.au/News/320617,redhat-project-fights-java-vulnerabilities.aspx > was published yesterday (25 Oct). > > On Mon, Oct 1, 2012 at 3:19 PM, Christian Heinrich > wrote: > > Grant, > > > > Below are the discussions related to Maven and the paper referenced: > > 1. http://krvw.com/pipermail/sc-l/2012/002786.html > > 2. http://krvw.com/pipermail/sc-l/2012/002788.html > > > > On Fri, Sep 28, 2012 at 9:10 AM, Grant Murphy > wrote: > >> I don't have the original mail but some time ago a thread on this list > >> mentioned this article: > >> > >> > http://www.sonatype.com/Products/Why-Sonatype/Reduce-Security-Risk/Security-Brief > > > -- > Regards, > Christian Heinrich > > http://cmlh.id.au/contact > -- Regards, Christian Heinrich http://cmlh.id.au/contact ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Security in open source components
Grant, ... and http://www.scmagazine.com.au/News/320617,redhat-project-fights-java-vulnerabilities.aspx was published yesterday (25 Oct). On Mon, Oct 1, 2012 at 3:19 PM, Christian Heinrich wrote: > Grant, > > Below are the discussions related to Maven and the paper referenced: > 1. http://krvw.com/pipermail/sc-l/2012/002786.html > 2. http://krvw.com/pipermail/sc-l/2012/002788.html > > On Fri, Sep 28, 2012 at 9:10 AM, Grant Murphy wrote: >> I don't have the original mail but some time ago a thread on this list >> mentioned this article: >> >> http://www.sonatype.com/Products/Why-Sonatype/Reduce-Security-Risk/Security-Brief -- Regards, Christian Heinrich http://cmlh.id.au/contact ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] Security in open source components
Grant, Below are the discussions related to Maven and the paper referenced: 1. http://krvw.com/pipermail/sc-l/2012/002786.html 2. http://krvw.com/pipermail/sc-l/2012/002788.html On Fri, Sep 28, 2012 at 9:10 AM, Grant Murphy wrote: > I don't have the original mail but some time ago a thread on this list > mentioned this article: > > http://www.sonatype.com/Products/Why-Sonatype/Reduce-Security-Risk/Security-Brief -- Regards, Christian Heinrich http://cmlh.id.au/contact ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] Security in open source components
I don't have the original mail but some time ago a thread on this list mentioned this article: http://www.sonatype.com/Products/Why-Sonatype/Reduce-Security-Risk/Security-Brief It might be of interest to you that the Red Hat Security Response Team has put together a database containing fingerprints of vulnerable Maven artifacts. We have just recently released a Maven Enforcer rule that scans a projects dependencies against the entries in this database. An example of the configuration options and the source code is available here: https://github.com/gcmurphy/enforce-victims-rule Try it out. I would be interested to get your feedback. Regards, Grant Murphy | Red Hat Product Security Team signature.asc Description: OpenPGP digital signature ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] security in open source components
On Tue, Apr 24, 2012 at 4:22 PM, Johan Peeters wrote: > I was very happy to see > http://www.sonatype.com/Products/Sonatype-Insight/Why-Insight/Reduce-Security-Risk/Security-Brief. > Finally some attention to the elephant in the room; what is the use of > secure coding if your software depends on third party components with > flaws? > ... > How can I be sure that the binary component my build script retrieves > from, say, Maven Central is the one released by the relevant open > source project? I know there are checksums and such, but I remain to > be convinced that this typically affords adequate protection or that > it even could do so... The problem with Maven in particular is the project stresses stability over all others. The project is more than happy to distribute stable, but buggy, code. How Stable vs Buggy is not muttually exclusive is an oxymoron to me, though. Jeff ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
Re: [SC-L] security in open source components
Johan, Since each git commit is SHA-1 and is popular with open source projects then it would be possible incorporate them as a "submodule" as part of your larger superproject within git but it does have some limitations outlined within http://stackoverflow.com/questions/996164/is-anyone-really-using-git-super-subprojects Let me know if this addresses your concern or if I am way off? On Wed, Apr 25, 2012 at 6:22 AM, Johan Peeters wrote: > These points are important. However, I am also concerned about > component distribution. > How can I be sure that the binary component my build script retrieves > from, say, Maven Central is the one released by the relevant open > source project? I know there are checksums and such, but I remain to > be convinced that this typically affords adequate protection or that > it even could do so. If my fears are well-founded, current > distribution mechanisms of open source components provide the ideal > opportunity for installing back-doors on the server side. > I hope I am just being paranoid and the authors neglected to talk > about distribution because it is obviously secure. I certainly would > have been happier if distribution had been analysed and found secure, > or, even, not terribly insecure. > Does anyone else share these concerns? Or can anyone allay my fears? -- Regards, Christian Heinrich http://cmlh.id.au/contact ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
[SC-L] security in open source components
I was very happy to see http://www.sonatype.com/Products/Sonatype-Insight/Why-Insight/Reduce-Security-Risk/Security-Brief. Finally some attention to the elephant in the room; what is the use of secure coding if your software depends on third party components with flaws? The paper makes some very good points on the general lack of governance for open source components. It mainly focuses on the lack of visibility and control of project dependencies. I.e. what does a build pull in? Are these trustworthy components? Does the build select component versions with flaws? Is any attention paid to security advisories and dependencies updated to versions with the flaws fixed? These points are important. However, I am also concerned about component distribution. How can I be sure that the binary component my build script retrieves from, say, Maven Central is the one released by the relevant open source project? I know there are checksums and such, but I remain to be convinced that this typically affords adequate protection or that it even could do so. If my fears are well-founded, current distribution mechanisms of open source components provide the ideal opportunity for installing back-doors on the server side. I hope I am just being paranoid and the authors neglected to talk about distribution because it is obviously secure. I certainly would have been happier if distribution had been analysed and found secure, or, even, not terribly insecure. Does anyone else share these concerns? Or can anyone allay my fears? kr, Yo -- Johan Peeters http://johanpeeters.com ___ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates ___
