forked from nccgroup/autopwn
-
Notifications
You must be signed in to change notification settings - Fork 0
/
ROADMAP
39 lines (30 loc) · 1.54 KB
/
ROADMAP
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
THOUGHTS
autopwn is going to change. In the not too distant future, the autopwn package
may only include a JSON API which will be able to serve different interfaces
for users (and other code). I want to take this approach for a few reasons:
1 - Cleaner code (separate logic and views)
2 - Easier to unit test
3 - Remote access possibility (this would not be introduced soon, but becomes
an avenue to explore later)
4 - Different views (CLI, web/mobile, API for other tools)
5 - Stateless (autopwn may not need to maintain state anymore, but
I haven't fully explored this area to make a definitive statement on this
yet. Obviously, the state will exist somewhere, maybe on the interfaces,
and when a decision is made, a single JSON query containing all relevant
info will trigger scans)
6 - Administrative capability (user login, audit etc)
7 - Multi-user
8 - Pretty pictures (with a web interface)
What this means is I'll probably have to write a separate command line
interface for autopwn (this may even be in a separate git repository). I will
also be looking into a web interface for autopwn (think Nessus, maybe).
In essence:
autopwn (JSON API) <--> clients (CLI, web/mobile, other tools)
Instead of:
autopwn (logic and CLI)
OTHER
I'm also looking into using a sqlite database for the tools and assessments.
The best reason I can give for this right now is the ability to run autopwn
as a service, and have new tools and assesments added without needing to
restart autopwn or reload the assets. I believe there are also other
advantages.