The Source Code Analysis Risk Evaluation project is a study to create a security complexity metric that will analyze source code and provide a realistic and factual representation of the potential of that source code to create a problematic binary. This metric will not say that the binary will be exploited nor does it do a static analysis for known limitations like vulnerabilities. However it will flag code for a particular interaction type or control and allow the developer to understand which Operational Security (OpSec) holes are not protected even if it can’t say the effectiveness of that protection at this time.

This computation will provide a final SCARE value, like the RAV, where 100% is the proper balance between controls to OpSec holes and no Limitations. Conversely, less than that shows an imbalance where too few Controls protect OpSec holes or Limitations in OpSec and Controls degrade the security.

The SCARE analysis tool is run against source code. Currently only C code is supported. The output file will contain all operational interactions possible which need controls (the current version does not yet say if and what controls are already there). At the bottom of the list are three numbers: Visibilities, Access, and Trusts. These 3 numbers can be plugged into the RAV Calculation spreadsheet available at http://www.isecom.org/ravs. The Delta value is then subtracted from 100 to give the SCARE percentage which indicates the complexity for securing this particular application. The lower the value, the worse the SCARE.

At this stage, the tool cannot yet tell which interactions have controls already or if those controls are applicable however once that is available it will change the RAV but not the SCARE. The SCARE will also not yet tell you where the bugs are in the code however if you are bug hunting, it will extract all the places where user inputs and trusts with user-accessible resources can be found in the code.

Currently, SCARE is designed to work for any programming language. While this methodology shows the C language, they need input and feedback from developers of other languages to expand this further.

If you are interested in helping with this project please contact ISECOM.

You can download SCARE here:

scare_analyst.zip

Or you can read more here.

LAPSE stands for a Lightweight Analysis for Program Security in Eclipse. LAPSE is designed to help with the task of auditing Java J2EE applications for common types of security vulnerabilities found in Web applications. LAPSE was developed by Benjamin Livshits as part of the Griffin Software Security Project.

LAPSE targets the following Web application vulnerabilities:

• Parameter manipulation
• SQL injections
• Header manipulation
• Cross-site scripting
• Cookie poisoning
• HTTP splitting
• Command-line parameters
• Path traversal

What should you do to avoid these vulnerabilities in your code? How do we protect Web applications from exploits? The proper way to deal with these types of attacks is by sanitizing the tainted input. Please refer to the OWASP guide to find out more about Web application security.

If you are interested in auditing a Java Web application, LAPSE helps you in the following ways:

• Identify taint sources
• Identify taint sinks
• Find paths between sources and sinks

LAPSE is inspired by existing lightweight security auditing tools such as RATS, pscan, and FlawFinder. Unlike those tools, however, LAPSE addresses vulnerabilities in Web applications. LAPSE is not intended as a comprehensive solution for Web application security, but rather as an aid in the code review process. Those looking for more comprehensive tools are encouraged to look at some of the tools produced by Fortify or Secure Software.

Read more about LAPSE HERE.

You can download LAPSE here:

LAPSE: Web Application Security Scanner for Java