2. Orizon Snapshot as November 2009 - What we
reached
Version 1.19
Parse
Java
JSP
C
PHP
Analyze
Crawl (only)
Report
Plain text
HTML
XML
265 downloads
We are able to eat our own
dog foo
OWASP 2
3. Orizon Snapshot as November 2009 - What we
failed
Community
People don’t feel excited from using the project
Completely lack of feedbacks
Developers
Too few contributors to the code
Goals
Orizon is NOT able to do a real static analysis
no taint propagation
no control flow diagram analysis
no valuable safe coding library
Orizon is far from being easy to use even for security specialists
something improved from last year but we’re years behind
Roadmap has been just some words written on a web page
OWASP 3
5. Roadmap from here to 2.0
goal: test.
goal:
implement. action: bugfix
goal: goal: and code
awerness. consolidate action:write review release:
. the code. Owasp
action:rethi release: Owasp orizon
nk the web action:rethi release: Owasp v2.0
Nov 2009 Jan 2010 apr 2010 may 2010 jun 2010
OWASP
6. Goals to reach
We need to better communicate the world how the project is
goal: moving.
awerness. People ask how they can participate. We must give such kind of
information dynamically in the web site.
Everybody will be able to figure it out the development status of
action:rethi
Orizon project, which are the areas where effort is needed and
nk the web how to join the project.
A better tool need a better internal than we have so far. goal:
To accomplish this a brand new architecture must be
consolidate
discussed and adopted in Owasp Orizon 2.0. .
action:rethi
OWASP 6
7. Goals to reach
It’s easy here.
goal: implement.
People need a tool to use in their code review.
action:write the code.
We just draw a great software architecture, than we have to
implement it.
release: Owasp orizon At the end of this stage, around April 2010, it will be
released Owasp Orizon version 1.70.
Starting from April, there will be 3 minor releases (1.75,
1.80 and 1.85) that will implement the 100% of features
intended to be provided by the tool.
Owasp Orizon APIs will be frozen in version 1.85 around the
end of April 2010.
Starting from May 2010, there will be a project phase
goal: test.
dedicated to software testing and security code review.
action: bugfix and code
The 1.90 release will be the last before the release candidate review
cycle (June 2010).
OWASP 7
8. Project phases
Prepare the
release package.
Prepare the site.
Prepare the
material for
Owasp AppSec
Brainstorm in 2010
mailing list Write code + documentation Prepare the
and over the All the code must be covered Owasp Orizon
blog. by javadoc Test Guide
Nov 2009 Jan 2010 apr 2010 may 2010 jun 2010
OWASP 8
9. Let’s start: some discussion about architecture
Source is “engine” based
3 major engines
2 minor, service engines
Users
fire up the shell
open a web root
crawl the sources
report the results
What’s bad?
there is no historical data
there is no link between scan and the
code being scanned
some ugly hacks are in the code
engines are contained almost each other
finding objects are stored in a very ugly
way in various scanning phase
there is some security check in the
modeling engine
OWASP 9
10. Key actions
“Ladies and gentleman, please welcome... the Project...”
“... and the marvelous Scan object”
Some refactoring is needed
Reportable? Finding instead
Collector as generic class for JspCollector, JavaCollector, CCollector
and friends? Man... it’s just a... Source
New package namespace
Defining use cases to address Owasp Orizon development,
user community and to spot other internal refactoring issues
Introducing persistence, a database as backend for
scan information
findings
it can be used GUIs (classic or web)
OWASP 10
11. The (Unofficial) Owasp Orizon 2.0 architecture
I
Parse assess report
Project &
plugin
Scan
subsyste
Managem
m
ent
(twilight, (tornado
kernel
core
OWASP 11
12. The (Unofficial) Owasp Orizon 2.0 architecture
II
osh web gui
Owasp Orizon SkyLine
Owasp
orizon library
Owasp Orizon core
(candlekeep
database backend
OWASP 12
13. Changes
Project & Scan Management
Project(s) will be logical entities modeling a software project Orizon will be
used onto
Scan(s) will be entities contained in a single project describing a security scan
performed in a particular timestamp.
SkyLine
is the real interface between kernel and library and the outsider world
deployed as standalone jar
Database backend
Orizon will be deployed with a lightweight key-value store DB (BerkleyDB ?)
Plugin can be written to support RDBMS with SQL
Web GUI: J2EE application using Grails.org framework
Library: ballot between
ORL, custom english like language to describe safe coding patterns
PQL, idea taken from newest works by Stephen Craig Evans
OWASP 13
14. What in the next update?
TBR: before 21st December 2009
Contains
a new state of art
feedback to this document
the new website mockups
Owasp Orizon 2 use cases
we need to understand what a Project is, how to manage
Projects, which objects are created internally with a Project, ...
we need to understand that a Scan is, how to manage Scan(s)
and so on
use cases will be used to describe the creation of internal objects
during each stage of Orizon utilization
OWASP 14
15. So next?
Join the mailing list if not yet done: http://svel.to/
cv
Grab the Orizon 1.1x source code:
svn co https://orizon.svn.sourceforge.net/svnroot/
orizon orizon
read it, understand it, love it
we will start from here
Follow the blog: http://svel.to/cw
Follow us on twitter: http://svel.to/cx
Share your opinions with us
OWASP 15