Researched by William Spires and Stephen Jensen. That Was Then, This is Now Just five short years ago, if you wanted to create an iOS application, you had to either take a crash course in Objective-C programming or hire someone to create the application for you. It was truly the beginning of a mobile revolution, […]
A large-scale deployment of the Veracode static code analysis tool across a large enterprise presents a number of unique challenges such as understanding your application estate, prioritising your applications for scanning, and communicating with your application owners. This blog post provides some guidance based on my experience at delivering several hundred scanned applications in a 14-month time frame.
Every December security companies pull out their list of predictions for the coming year. These predictions are generally bland, and either cite the specific problem the company addresses as the big trend for the next year, or recycles predictions from previous years.
Rather than add to the noise, the Security Research Team at Veracode created a list of resolutions for 2014 that developers could use to help make their code more secure.
Ranked at number eight on the 2013 OWASP Top Ten, Cross Site Request Forgery (CSRF) remains a major concern. CSRF manipulates a web application vulnerability which allows an attacker to trick the end user into performing unwanted and possibly sensitive actions.
Christmas, 2013 will be a banner year for the Internet of Things, as smart gadgets appear like mushrooms under the Christmas tree. But get ready for a privacy hangover, as poorly designed, and insecurely deployed gadgets turn on their masters.
Just in time for the holidays, I received an e-mail by way of Electric Imp. If you’re not familiar with the “Imp,” (my phrase, not theirs), it’s a [PAAS?] that makes it easy to build and connect smart devices.
In this series, we’ve advocated that Application Security is best pursued as a sustained, policy-driven program that employs proactive, preventative methods to manage software risk. This Maturity Curve model has been validated by Veracode using the real world results of hundreds of organizations. They have learned that the key to positive return on investment is to start small and scale up over time with each milestone.
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.
Businesses run on software; it gives us the features and functions needed to make our teams more productive However, these applications and providers build, maintain, and host critical systems as well as high risk data and need to apply the same controls we use. Financial Services are inherently accountable for the risk from vulnerabilities in the software that serves our customers and employees. Too few enterprises have adapted to the growing attack surface of web applications by addressing vendor software security.
With reports of website vulnerabilities and data breaches regularly featuring in the news, securing the software development life cycle (SDLC) has never been so important. The enterprise must, therefore, choose carefully the correct security techniques to implement. Static and dynamic analyses are two of the most popular types of security test. Before implementation however, the security-conscious enterprise should examine precisely how both types of test can help to secure the SDLC. Testing, after all, can be considered an investment that should be carefully monitored.
What’s wrong with the following C code?
char buf; scanf("%32s", buf);
It’s a classic and easy to make off-by-one error, caused by the willy-nilly inconsistency of common C functions regarding whose responsibility the null terminator is and whether it’s included in a passed count of bytes. In this case,
scanf() will read up to 32 bytes from standard input and then append a null terminator, which overflows the buffer of 32 characters and writes a null byte to whatever happens to be next on the stack.