[Owasp-leaders] jowasp.org

Colin Watson colin.watson at owasp.org
Thu Aug 28 07:30:16 UTC 2014

Jim etc

A great idea. But it can't be a free-for-all, as decisions here impact on:

1. other volunteers
2. administrative resources
3. the security of www.owasp.org
4. the reputation of OWASP Foundation


Firstly, it sounds like these microsites might relate to:

- language (e.g. Java)
- framework (e.g. dotnet)
- project (e.g. proactive)
- role (e.g. defenders)
- initiative (e.g. government)
- chapter (e.g. nyc)
- region (e.g. asia)
- topic (e.g. risk/vulnerability)

Focusing on just say the language idea, if there is java. but not
php., what does that indicate to outsiders?

Focusing on  projects. If a project has a microsite, does that
undermine all the projects that don’t? It appears from other posts to
this list that many projects are either empty shells or not
maintained. There needs to be some threshold for volunteers to apply
for the right to have a subdomain, and their other
project(s)/contributions must already meet a certain high standard
(quality, freshness, support).

Focusing on a risk/vulnerability, why should xss.owasp.org exist but
not csrf.owasp.org for example, or should the latter be
xsrf.owasp.org? Who decides what will be okay?

Is there a danger that only "rich" leaders/chapters will be able to
create these microsites, if “pro design” and “SSL certificate” have to
be acquired?

There will be a lot more new OWASP support overhead for these
microsites such as approving them ,setting up the DNS records,
managing access, maintaining assets, and periodic review.

A final question on subdomains, how does the wiki deal with other
languages? I believe Spanish exists. Are there any subdomains already

Not a free-for-all

So, some initial discussion ideas for ground rules:

a) All sub-domain DNS will be managed by OWASP (of course)

b) No new domain names must be registered (to prevent sprawl, lack of
control and brand damage)

c) All sites must be hosted within OWASP’s infrastructure (so OWASP
has all the assets, and backups)

d) All root/admin access credentials must be held and controlled by
OWASP, not any project leader or other person (so that OWASP can
transfer ownership to another lerader, or take thje site down if not
maintained, or is contrary to any principle)

e) Must conform to OWASP’s domain-level policies (e.g. RIA, HSTS?).
What content/includes will be allowed or not. Some might well
undermine the security of the main website.

f ) Must be SSL-only

g) No sponsorship/advertising at all (because that is occurring on a
tab of the project page).

h) Must not contravene OWASP’s principles and ethics, or any governance rules

i) Must not have any? vulnerabilities!

j) Must use 2FA for administrative access for all non-public access

k) Must support multilingual capabilities

l) Microsites will be culled if not updated within any rolling period
of (say) 180days.

m) Content must be relevant, accurate, timely and be well written

n) Vendor neutral

o) (your suggestions)


More information about the OWASP-Leaders mailing list