Welcome to another round of Agile SDLC Q&A. Last week Ryan and I took some time to answer questions from our webinar, “Building Security Into the Agile SDLC: View from the Trenches“; in case you missed it, you can see Part I here. Now on to more of your questions! Q. What would you recommend […]
Recently, Ryan O’Boyle and I hosted the webinar “Building Security Into the Agile SDLC: View From the Trenches”. We would like to take a minute to thank all those who attended the live broadcast for submitting questions. There were so many questions from our open discussion following the webinar that we wanted to take the […]
So you’ve got upper management buy-in for your application security proof of concept and are ready to start scanning applications: how do you make sure your proof of concept (PoC) is a success and that you demonstrate the need to progress to a full scale program. This article describes some of the lessons learned at the start of our large-scale deployment of Veracode within our organisation.
The first step is to socialise the PoC internally through word of mouth, discussion forums, and developer communities by driving interest in the availability of a new tool for developers, which will assist in the development process and produce better code.
As a pentester, it’s always a different story when we are the ones writing the report. Being on the receiving end is stressful, even more so when you throw compliance into the mix. I figured since I have been fielding questions left and right about what to do when it comes to mobile applications and HIPAA compliance, I would simply write a blog post on the topic.
At On-Line Strategies [OLS], many of the tools we use in our Software Development Lifecycle (SDLC) have helpful APIs, including Veracode. We leverage them to automate tasks that were once performed manually by developers or technical managers, such as running a Veracode static scan on a pending release.
Today, our Veracode static scans run alongside automated regression tests for every public release, to ensure we catch security flaws that may have slipped by our developers.
In the last year or so that I’ve been a member of Veracode’s Customer Success team, I’ve found that I have been hearing the same remarks from an array of organizations- “We must implement Secure Coding practices in order to retain a positive brand image, but we’re up against very strict deadlines and need to get our code out fast!” As we work with Security and Development teams alike, this statement starts a discussion which typically unravels until we get to a question that is asked again and again…
When I studied computer science in college, the curriculum wasn’t designed to teach all the different programming languages with the goal of becoming as “multi-lingual” as possible. Instead we focused on conceptual areas — data structures, machine structures, algorithms, etc. The languages with which you chose to illustrate those concepts were secondary to the concepts themselves. I believe most leading research universities emphasize concepts over mechanics in a similar fashion.
A developer’s main goal usually doesn’t include creating flawless, intrusion proof applications. In fact the goal is usually to create a working program as quickly as possible. Programmers aren’t security experts, and perhaps they shouldn’t be. But when 70% of applications failing to company with enterprise security standards (data from Veracode SoSS vol 5), it is clear more attention needs to be given to secure programming techniques.
Join Chris Wysopal, our CTO and Co-Founder, as he breaks down the present and future state of application security. He will dive into the data that drove the predictions detailed in Veracode’s fifth annual State of Software Security Report. This report pulls data from tens of thousands of live application scans performed on the Veracode Platform.
It’s only a matter of time before someone finds all the skeletons in your closet. In this case the “someone” is a hacker and the “closets” are your applications. As if that isn’t scary enough, consider all of the 3rd party applications and libraries being leveraged to make your applications function…and all of their skeletons you don’t know of. No bones about it, there’s a whole heap of issues that can no longer accept failure as the norm.