Re: [SC-L] A new blog on application security - armoredcode.com
On 21 March 2012 13:55, Jeffrey Walton wrote: > On Fri, Mar 16, 2012 at 12:50 PM, Paolo Perego > wrote: > > If you would like to add it on your feed, it would be great. > For the love of , please discuss the tool chain's static > analysis capabilities, and suggest a clean compile as a security gate > (gcc: -Wall -Wextra -Wconversion). > Hi Jeff, thanks for the suggestion... I was arguing if there were people interested in plain old school security applied to non web application. Of course I'll cover static analysis and how to use compilers and interpreters to spot security bugs... I think some posts to recap what a buffer overflow or format bug vulnerabilities are can be useful, what do you think about it? Does it make sense? >From my experience, its nearly impossible to 'quick audit' a GNU > project. Entering `make CFLAGS="-Wall -Wextra -Wconversion ..." causes > so much output its difficult to locate/triage issues. > It is... in this case, some grep command lines are more useful but it's a very interesting topic to go deeper. > You will be swimming against the tide with some of the l33t k3rn3l > hack3rz: "Gcc is crap" [1]. > All assumptions about how perfect are compilers or interpreters go to /dev/null. Software is written by humans, so all software is bugged by definition. All checks are necessary . Paolo -- "... static analysis is fun, again!" life from an application security guy ~> http://armoredcode.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 ___
[SC-L] A new blog on application security - armoredcode.com
Hi list, just 2 lines for promoting my new blog on application security: http://armoredcode.com The idea is to talk about appsec using the developers language so talking about testing frameworks and practices, libraries to enforce security, how to read a penetration test report, some "hands on" with live code examples and some interviews with appsec and developers superstar. If you would like to add it on your feed, it would be great. Thanks Paolo -- "... static analysis is fun, again!" life from an application security guy ~> http://armoredcode.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 ___
[SC-L] Project announce: The OWASP Source Code Flaws Top 10
Hello leaders, I'm really happy to announce a new documentation project I started today. Our Top 10 most critical web app vulnerabilities is the standard de facto when trying to summarize findings when you assess a web application. And it is great. Looking at source code assessment (or code review, or static analysis, or whatever the name you want to use :-)), nothing like this exists. Gary McGraw introduced the 7 kingdoms as taxonomy. I started looking at this great job extending it to meet Owasp Top 10 like template. I also used categories that I found useful to gather security code review findings in. That's why I started this Top 10 project. The goal is to provide something useful in Owasp Code Review Guide while trying to organize security issues and the second goal is to use it as Owasp Orizon default library cookbooks in order to have a "fil rouge" from Code review guide and the implementing tool. The Source code flaws Top 10 will be that fil rouge. I really hope that everyone interested will subscribe to mailing list and give some contributions to this document I'd like to release as beta quality project in the next AppSec Europe 2009 in Cracow. Link: http://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project Roadmap: http://www.owasp.org/index.php/Category:OWASP_Source_Code_Flaws_Top_10_Project_Roadmap Mailinglist subscription page: https://lists.owasp.org/mailman/listinfo/owasp-source-code-flaws-top-10 Regards thesp0nge -- "stay hungry, stay foolish" OWASP Orizon project, http://orizon.sourceforge.net "enjoy your code review experience" ___ 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. ___
Re: [SC-L] Code review pool
Please apologies me. I figure out just know that livejournal.com doesn't allow poll to be complete without a valid livejournal.com account or openId. So if you are not livejournal users and you don't want to became one of them, you could answer the poll to me using email and I'll publish results to another post to my blog. Again sorry :( thesp0nge On 05/11/2007, ljknews <[EMAIL PROTECTED]> wrote: > At 12:50 PM +0100 11/5/07, Paolo Perego wrote: > > > Hi guys, trying to improve Owasp Orizon project in a better way, I > > released a poll over my blog here: > > http://thesp0nge.livejournal.com/5687.html > > > > It would be great having your feedback about your vision to code > > review and safe coding as developers and security specialist. > > I see a bunch of links called "View Answers" along with a link > called "Poll #1083138". > > Clicking on the "Poll #1083138" link takes me to a page of answers. > -- > Larry Kilgallen > ___ > 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. > ___ > -- Owasp Orizon leader orizon.sourceforge.net ___ 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. ___
[SC-L] Code review pool
Hi guys, trying to improve Owasp Orizon project in a better way, I released a poll over my blog here: http://thesp0nge.livejournal.com/5687.html It would be great having your feedback about your vision to code review and safe coding as developers and security specialist. Thanks for participating. Regards thesp0nge -- Owasp Orizon leader orizon.sourceforge.net ___ 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. ___
[SC-L] Orizon v0.50 announce
Hi there, I'd like to announce as delivery for Owasp Spring of Code 2007 project, the 0.50 release of Orizon. Orizon is a source code review engine, built with the aim to give developers something usable to build code review tools. Orizon is independent from the language used to write the sources because its APIs translate the code in a XML file and APIs are provided to apply security checks over the translated XML file. By now just Java programming language is supported in XML translation but I'm planning to add C# support very soon. Orizon is written in Java and is provided with a small default library containing 20 security checks. Orizon is waiting for developers wanting to extends the engine and also people who wants to provide further security checks to be added into the library. It would be great having your feedback, your opinions, your bug reports in order to improve my project. Links: Orizon site: http://orizon.sourceforge.net Milk site, a code review tool I'm writing and that uses Orizon: http://milk.sourceforge.net Regards, thesp0nge -- Owasp Orizon leader orizon.sourceforge.net ___ 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. ___
Re: [SC-L] Perspectives on Code Scanning
James, and all list please apologies for my bad english usage. Looking at your reply I understood I espressed my thoghuts playing bad with words. By saying that vendors has to follow developer licensing, I intended that in my opinion is good that vendors still build tool to aid developers not only executives as some mail in this thread would suggest. I do agree that tool designed to assist developers in writing secure code has to be free and open. I'm writing one of this tool, indeed it's a framework to build such tools but it's not an important different in this topic. I think that an open source approach is the winning here not just for saving money in buying tools but for the widespread knowledge shared among developers and security experts writing the tool itself. Sorry for my firmer mail that doesn't show correctly what is my opinion. The framework for code review tool I'm writing is an owasp project, hosted at sourceforge: http://orizon.sourceforge.net Ciao ciao thesp0nge On 6/8/07, McGovern, James F (HTSC, IT) <[EMAIL PROTECTED]> wrote: > In a previous thread someone appropriately commented that perspectives in > this space differ depending upon whether you are a software vendor, > government customer or enterprise. I do not disagree that developers need to > know how to fix their code. What I am saying is that tools to assist > developers in writing better could should be free. > > Your quote "*imho* vendor has to follow developer licensing" is where I think > it will harm the goals of secure coding at large. Consider the trend within > the industry that tools for software development are essentially becoming > free. No one pays for IDEs (rare exceptions) when things like Eclipse and > Visual Studio have free versions. > > Enterprise folks however will pay lots of money for tools in the auditing > space that help them to quantify risk. The ability to scan large multiple > code bases is a different product/problem than scanning while writing code in > an IDE. I am saying that more money could be had if folks focus on the first > and not the later. Vendors who get it twisted by focusing on the number of > developers are dillusional and should ask themselves why aren't but a select > few of any enterprise pervasively deploying tools to developers. > > Give away the developer tools in the same way Microsoft does and you will > accelerate your potential sales from the bottom up. Not all sales within > places are driven top down... > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Paolo Perego > Sent: Friday, June 08, 2007 5:40 AM > To: McGovern, James F (HTSC, IT) > Cc: Secure Coding > Subject: Re: [SC-L] Perspectives on Code Scanning > > Hi there, I found this thread very interesting. > It's true that developers are the ones who remediate to code > insecurity and executives care about how much effort has to be spent > over closing branches. Indeed I think the two categories needs a tool > approaching the same problem (tell if a code follows security best > practices or not) showing results in 2 "different" languages. > > Developers need how to know how to fix their code. Executives need to > know how much these fixes cost, who will attend them and in how many > time fixes will be committed. > > *imho* vendor has to follow developer licensing... since developer do > knows ho to write code but he has to be helped in writing it in a > secure way. > > Safe coding is a concern for both developers than executives. > My 2 euro cents > > Ciao ciao > thesp0nge > -- > Owasp Orizon leader > orizon.sourceforge.net > ___ > 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. > ___ > > > * > This communication, including attachments, is > for the exclusive use of addressee and may contain proprietary, > confidential and/or privileged information. If you are not the intended > recipient, any use, copying, disclosure, dissemination or distribution is > strictly prohibited. If you are not the intended recipient, please notify > the sender immediately by return e-mail, delete this communication and > destroy all copies. > * > > >
Re: [SC-L] Perspectives on Code Scanning
On 6/6/07, McGovern, James F (HTSC, IT) <[EMAIL PROTECTED]> wrote: > I really hope that this email doesn't generate a ton of offline emails and > hope that folks will talk publicly. It has been my latest thinking that the > value of tools in this space are not really targeted at developers but should > be targeted at executives who care about overall quality and security folks > who care about risk. While developers are the ones to remediate, the > accountability for secure coding resides elsewhere. Hi there, I found this thread very interesting. It's true that developers are the ones who remediate to code insecurity and executives care about how much effort has to be spent over closing branches. Indeed I think the two categories needs a tool approaching the same problem (tell if a code follows security best practices or not) showing results in 2 "different" languages. Developers need how to know how to fix their code. Executives need to know how much these fixes cost, who will attend them and in how many time fixes will be committed. *imho* vendor has to follow developer licensing... since developer do knows ho to write code but he has to be helped in writing it in a secure way. Safe coding is a concern for both developers than executives. My 2 euro cents Ciao ciao thesp0nge -- Owasp Orizon leader orizon.sourceforge.net ___ 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. ___
Re: [SC-L] "Bumper sticker" definition of secure software
Hi list, I'll introduce myself with a claim: "Software is like Titanic, pleople claim it was unsinkable. Securing is providing it power steering" thesp0nge On 7/18/06, Gadi Evron <[EMAIL PROTECTED]> wrote: On Mon, 17 Jul 2006, Rajeev Gopalakrishna wrote:> Reliability is concerned only with accidental failures while security has > to consider malicious attacks as well. The difference is in the intent of> the software user: benign or malicious.>> And for a bumper sticker, here is one for the pessimists:>> "Secure Software is a Myth" >> and another version for the skeptics:>> "Is Secure Software a Myth?">> :)Again, this would speak only to a very small percentage of thepopulation. You me, maybe 10K people around the world if we are generous. >> -rajeev>>> On Mon, 17 Jul 2006, Peter G. Neumann wrote:>> > You suggest:> >> > Secure software is software that remains dependable despite efforts to > > compromise its dependability.> >> > You need a bigger-picture view that encompasses trustworthiness> > and assurance.> >> > "Dependable systems are systems that remain dependable despite > > would-be compromises to their dependability."> >> > "Trustworthy systems are systems that are worthy of being trusted> > to satisfy their requirements (for security, reliability, survivability, > > safety, or whatever)."> >> > Security is generally too narrow by itself, because a system that is> > not reliable is not likely to be secure, especially when in> > unreliability mode! > >> > The principle of Keep It Simple is inherently unworkable with respect to> > security. Security is inherently complex. Trustworthiness is broader and> > even more complex. But if you don't think about trustworthiness more > > broadly, what you get is not likely to be very secure.> >> > Forget the bumper sticker approach.> >> > ___> > 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> >> ___> 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>___Secure Coding mailing list (SC-L) SC-L@securecoding.orgList information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-lList charter available at - http://www.securecoding.org/list/charter.php-- $>cd /pub$>more beerAngeL core developer: http://www.sikurezza.org/angel ___ 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
