Hi all,
I recently discovered the project SATEC. I would like to proposed few
modifications to the document.
Expanding "Tool Coverage" (section 3)
Few sub-sections should be added.
(include simply for distinction with the following)
- Language support : Ability to point line of code. Ability to
trace variables flows, method calls and implicit dependencies when needed.
- Framework : Support for the frameworks used. Ability to recognize
the Authentication framework use.
- Library and API : Ability to recognize the API used for database access,
access to file system, etc.
- Internal API : Ability to expand the tool to integrate custom API created
internally by the company. (Similar to section 4.3)
(3.4 -"... Understand components" could be reformulate to Configurations)
Product Update Process * (section 7)*
On my first read, I thought the section 7 (which end up in section 4 on the
first draft) was not appropriate to the Code analysis context .
Static code analysis is very different from malware analysis. Every new
binaries in malware analysis is likely to have been
packed/obfuscated differently.
In development, the framework and languages used do not evolve rapidly.
From time to time, libraries are introduce to support new functionalities.
But there are no 0 day API. ;)
I'm not trying to demolish the previous work. I think the criteria list was
pretty complete.
That's it .. I hope I'll be able to collaborate on the project.
===
Just for transparency: I have started a weekend project called
Find-Security-Bugs http://h3xstream.github.com/find-sec-bugs/. The tool
doesn't have an ultra advanced detection engine. My goal is not to make
this small project more visible through this document.
--
Philippe Arteau
Hi all,
I recently discovered the project SATEC. I would like to proposed few
modifications to the document.
*Expanding "Tool Coverage" (section 3)*
Few sub-sections should be added.
(include simply for distinction with the following)
- Language support : Ability to point line of code. Ability to
trace variables flows, method calls and implicit dependencies when needed.
+ Framework : Support for the frameworks used. Ability to recognize
the Authentication framework use.
+ Library and API : Ability to recognize the API used for database access,
access to file system, etc.
+ Internal API : Ability to expand the tool to integrate custom API created
internally by the company. (Similar to section 4.3)
(3.4 -"... Understand components" could be reformulate to Configurations)
*Product Update Process* * (section 7)*
On my first read, I thought the section 7 (which end up in section 4 on the
first draft) was not appropriate to the Code analysis context .
Static code analysis is very different from malware analysis. Every new
binaries in malware analysis is likely to have been
packed/obfuscated differently.
In development, the framework and languages used do not evolve rapidly.
>From time to time, libraries are introduce to support new functionalities.
But there are no 0 day API. ;)
I'm not trying to demolish the previous work. I think the criteria list was
pretty complete.
That's it .. I hope I'll be able to collaborate on the project.
===
Just for transparency: I have started a weekend project called
Find-Security-Bugs <http://h3xstream.github.com/find-sec-bugs/>. The tool
doesn't have an ultra advanced detection engine. My goal is _not_ to make
this small project more visible through this document.
===
--
Philippe Arteau
