1 |
Alex. |
2 |
|
3 |
For WEB vulnerability discovering, one of the most important to us is Nessus |
4 |
to |
5 |
search and confronting against CVE database. Sometimes, Nessus find some |
6 |
vulnerable packages in our Gentoo boxes and when we go to emerge -UDN this, |
7 |
there is not the updated version even when the fixes are available [in other |
8 |
distros |
9 |
for example]. |
10 |
|
11 |
The Core Impact |
12 |
|
13 |
http://www.coresecurity.com/ |
14 |
|
15 |
do a great job too but we only tested the demo version. [That is great too]. |
16 |
|
17 |
There is other interesting tool [not really WEB related but...] the Secunia |
18 |
PSI |
19 |
|
20 |
http://secunia.com/vulnerability_scanning/online/ |
21 |
|
22 |
that do a great job in search unupdated packages but Windows only. |
23 |
|
24 |
Reading your last answer, I had the impression we are talking about |
25 |
different things but I think |
26 |
I can connect them. My apologies to speculate without read the complete team |
27 |
work documentation |
28 |
but even if issue correction is not our job as you said, I think we could |
29 |
pressure package maintainers |
30 |
to update its packages since we (in thesis) have more visibility about |
31 |
packages vulnerabilities that can be fixed but |
32 |
aren't fixed yet. This could be impact even in GLSA's update for example. |
33 |
|
34 |
So, if we have a automatic mechanism that searchs into vulnerabilities |
35 |
databases - CVE - for example and find what |
36 |
packages have issues that was already fixed, we could, for example, label |
37 |
packages |
38 |
with some flag that tells users and developers that this package needs |
39 |
review to fix some vulnerability. |
40 |
|
41 |
I thought this is an interesting point to discuss because this could in |
42 |
principle force updates to be more |
43 |
fast and more Bugzilla-free. I have nothing against Bugzilla but the process |
44 |
as a whole takes too much time |
45 |
and we could in principle search vulnerabilities databases and provide |
46 |
developers and users with informations |
47 |
about how their systems security are. |
48 |
|
49 |
Thanks again. |
50 |
|
51 |
Daniel |
52 |
|
53 |
On Fri, Aug 26, 2011 at 3:44 PM, Alex Legler <a3li@g.o> wrote: |
54 |
|
55 |
> On Friday 26 August 2011 15:22:40 Daniel A. Avelino wrote: |
56 |
> > > When I think about automation, I had in mind something that could help |
57 |
> > |
58 |
> > developers to find |
59 |
> > vulnerabilities in a more fast way [searching and confronting CVE, for |
60 |
> > example] and start a |
61 |
> > "call for solution" process. I work with solutions of this type for WEB |
62 |
> > vulnerabilities discover |
63 |
> > and some tools are very interesting to reduce the correction time. |
64 |
> > |
65 |
> |
66 |
> We already use CVE as one of our sources of vulnerability intelligence. |
67 |
> Finding issues is also not the real issue here. |
68 |
> Also, actual issue correction is not our job, it's the responsibility of |
69 |
> the |
70 |
> package maintainer. |
71 |
> |
72 |
> Can you share details about the utilities you are using? |
73 |
> |
74 |
> Alex |
75 |
> |
76 |
> -- |
77 |
> Alex Legler <a3li@g.o> |
78 |
> Gentoo Security / Ruby |