The SAMATE Project Department of Homeland Security



Static Analysis Summit II

A SAMATE meeting

Jefferson Memorial by Christopher
Hollis, Wdwic Pictures

November 8 & 9, 2007

at SIGAda 2007

Hyatt Fair Lakes Hotel

Fairfax, Virginia, USA



"Black-box" software testing cannot realistically find maliciously implanted Trojan horses or subtle errors which have many preconditions. For maximum reliability and assurance, static analysis must be applied to all levels of software artifacts, from models to source code to byte code to binaries. Static analyzers are quite capable and are developing quickly. Yet, developers, auditors, and examiners could use far more capabilities. As noted in the CFP the goal of this summit is to convene researchers, developers, and government and industrial users to define obstacles to such urgently-needed capabilities and try to identify feasible approaches to overcome them, either engineering ("solved" problems) or research.

This follows the first Static Analysis Summit in June 2006. The next workshop will be co-located with PLDI in 2008.

We solicit contributions of papers or proposals for discussion sessions. Contributions should describe basic research, applications, experience, or proposals relevant to static analysis tools, techniques, and their evaluation. Questions and topics of interest include but are not limited to:

  • How can embedded, SCADA, uncommon, etc. systems be analyzed?
  • Binaries need to be handled better - how is that possible?
These are important for 3rd party validation, legacy systems, contract work, and getting by without a trusted compiler. How can binary analysis capabilities be developed and minimize theft of IP?
  • Obfuscation vs. analysis - which will win?
Malware writers use obfuscation to disguise their programs and hide their exploits and behavior. Good guys need powerful analysis to crack the malware quickly. Good guys also use obfuscation to protect intellectual property, and in military application, hinder enemies from figuring out weapon systems (remember the Death Star?). They don't want the bad guys to be able to crack their techniques. So will the obfuscators or the analysts win? Why?
  • Good software starts with good design. What is the state of the art in static analysis, especially for security, at the design or requirements level?
  • Higher level function extraction.
Static analyzers identify specific patterns, but sometimes we want a tool to summarize the behavior in higher level abstractions, like sorting or encoding a message. What can be done? Where is it most beneficial? What are the approaches?
  • Temporal and inter-tool information sharing.
Static analyzers do a lot of work to produce their result, for instance, data and control flow graphs. Yet the work is generally not available, to other tools or even to the same tool on subsequent runs. Can we define useful information (and representations) to share with other tools to build assurance cases? Could we speed up or improve analysis with certificates or hints from early stages? Could we hook the output to the input and get useful incremental analysis? Are concepts like proof-carrying code helpful?
  • What is the minimum performance bar for a source code security analyzer?
  • Static analysis' contribution to software security assurance
  • Flaw catching effectiveness of methods, techniques, or tools
  • Benchmarks or reference datasets
  • Formal pattern languages to describe vulnerabilities.
Most static analyzers have means for the user to specify what to search for. Unfortunately analyzers have different means. Significant resources are going into writing a public library of security weaknesses, see Formally describing a pattern is very tedious. It would be nice if different tools and processes could share patterns. The community should discuss what form of language or specification makes the most sense.
  • Software security assurance metrics
  • User experience drawing useful lessons or comparisons


Papers should be from 1 to 8 pages long. Papers over eight pages will not be reviewed. Papers should clearly identify their novel contributions.

Discussion session proposals should give a session title and name a moderator and at least two other participants. The proposal should clearly identify the topic or question for discussion.

Submit papers and proposals electronically in PDF or ASCII text by 3 September 2007 to Wendy Havens <>. (We will need ACM copyright forms.)

We will notify submitters of acceptance by 3 October 2007.


You do not have to have an accepted paper or discussion proposal to attend. We invite those who develop, use, purchase, or review software security evaluation tools. Academicians who are working in the area of semi- or completely automated tools to review or assess the security properties of software are especially welcome. We are encouraging participation from researchers, students, developers, and users in industry, government, and universities.

You must register for at least one day of SIGAda 2007. There is no additional charge to attend the summit. It only costs $25 for one day registration for full-time students.

On-line registration is now closed. You can register on-site.


Thursday, 8 November

12:30 PM: Program Presentation and Charge to Attendees - Paul E. Black

12:45 : Static Analysis for Improving Secure Software Development at Motorola - R Krishnan, Margaret Nadworny, and Nishil Bharill

1:10 : Discussion: most urgently-needed capabilities in static analysis

1:40 : Evaluation of Static Source Code Analyzers for Real-Time Embedded Software Development - Redge Bartholomew

2:05 : Discussion: greatest obstacles in static analysis

2:35 : Break

2:50 : Common Weakness Enumeration (CWE) Status Update - Robert Martin and Sean Barnum

3:15 : Discussion: possible approaches to overcome obstacles

Moderator: Redge Bartholomew

3:45 : Panel: Obfuscation vs. Analysis - Who Will Win?

David J. Chaboya AFRL
Stacy Prowell CERT

4:30 : New Technology Demonstration Fair

static analysis of x86 executables

Friday, 9 November

8:30 AM: Discussion: Static Analysis at Other Levels

Source analysis dominates. Where are the requirements or design analyzers? Some say binary analysis is intractable. Others say they have it. Everyone needs it.
Moderator: Michael Kass

9:00 : Keynote: Bill Pugh

Judging the Value of Static Analysis abstract

10:00 : Break

10:15 : A Practical Approach to Formal Software Verification by Static Analysis - Arnaud Venet (to be given by Henny Sipma)

10:40 : Discussion: inter-tool information sharing

What information would help static analysis? What information can an analyzer provide?

11:10 : Logical Foundation for Static Analysis: Application to Binary Static Analysis for Security - Hassen Saidi

11:35 : Wrap up discussion: needs, obstacles, and approaches

What should we recommend?


Accepted papers and discussion notes will be published in Ada Letters.


23 August 2007 - on-line registration opens
  3 September 2007 - Paper submission deadline
  3 October 2007 - Author notification
22 October 2007 - Final publication-ready copy due
  1 November 2007 - Last date to register for Early Conference Rate
8 & 9 November 2007 - Summit



Paul E. Black NIST

Program Committee

Paul AndersonGrammaTech
Thomas BallMicrosoft Research
Redge BartholomewRockwell Collins
Ira BaxterSemantic Designs
Rogier BoonITsec Security Services
Chandrasekhar BoyapatiU. Michigan
Rod ChapmanPraxis High Integrity Systems
Brian ChessFortify
Ben ChelfCoverity
Ron CytronWashington University
Jack DanahyOunce Labs
Mary Ann DavidsonOracle
Dawson EnglerStanford
Gene FredriksenBurton Group
John HatcliffKSU
Chris HoteThe MathWorks, Code Verification Products
Susan HorwitzU. Wisconsin
Joe KiniryUniversity College Dublin
Nikolai MansourovKDM Analytics
W. Bradley MartinNSA
James W. MooreThe MITRE Corporation
David NaumannStevens Institute
Bill PughU. Maryland
Daniel J. QuinlanLLNL
Martin RinardMIT
Radu RuginaCornell
Mark SaaltinkCommunications Security Establishment
Koushik SenBerkeley
Sergei SokolovParasoft
Arnaud VenetKestrel Technology
Bob WarneCESG