This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "OWASP Secure Software Contract Annex German"
Line 36: | Line 36: | ||
OWASP möchte sich an dieser Stelle ausdrücklich vielmals für die umfaßende Unterstützung durch Aspect Security während der Recherche und Vorbereitung für dieses Dokuments bedanken. | OWASP möchte sich an dieser Stelle ausdrücklich vielmals für die umfaßende Unterstützung durch Aspect Security während der Recherche und Vorbereitung für dieses Dokuments bedanken. | ||
+ | |||
+ | ==EINWÄNDE== | ||
+ | Die folgenden Seiten behandeln oft eingeführte Einwände gegen die Nutzung dieser Formulierungen in Zusammenhang mit Softwareentwicklungsverträgen | ||
+ | |||
+ | ===ABER NICHT ALLE BESTIMMUNGEN TREFFEN AUF UNS ZU...=== | ||
+ | Dieses Dokument sollte als Ausgangspunkt Ihres Vertrages angesehen werden. Möglicherweise gefallen Ihnen nicht alle Maßnahmen oder Sie wollen Ihrem Vertragspartner mehr vorschlagen. Vielleicht wollen Sie Haftungsfragen anders regeln. Dieses Dokument beabsichtigt nicht exakt die Bedürfniße jedes einzelnen Softwarekunden und Softwareentwicklers aufzugreifen. Es beabsichtigt vielmehr ein Rahmenkonzept bereitzustellen, an Hand deßen die Schlüßelthemen diskutiert werden können, die maßgeblich sind, um sicherzustellen, daß am Ende eine sichere Software herauskommt. Nach Ihrem Gespräch über die Softwaresicherheit und dem Treffen einer Vereinbarung, sollten Sie diese auf sich maßschneidern. | ||
+ | |||
+ | ===ABER WER SOLL FÜR DIESE MAßNAHMEN ZAHLEN...=== | ||
+ | Bei diesem Vertrag geht es NICHT darum, den Softwareentwickler mehr zu belasten. Es stellt sich nicht die Frage, ob Sicherheit mit Kosten einhergeht - natürlich, lautet die Antwort. Die beßere Frage lautet eher, welche Maßnahmen beide Parteien ergreifen sollten, um diese Kosten zu senken und zu welchem Zeitpunkt. | ||
+ | |||
+ | Diese ergänzenden Vertragsbedingungen schweigen bewußt darüber, wer die Kosten dieser Maßnahmen tragen sollte. Während viele dieser Maßnahmen bereits greifen sollten, was auch von vielen Kunden erwartet wird, werden sie nicht regelmäßig von der Industrie angewandt. Die Frage danach, wer (und wie viel) zahlt, sollte Gegenstand der Verhandlung sein. | ||
+ | |||
+ | Kosten für Sicherheitsmaßnahmen zu berechnen, ist sehr schwierig. Einerseits gibt es Kosten, die auf der Ausführung von Sicherheitsmaßnahmen beruhen und andererseits entstehen erhebliche Kosten erst, wenn man Sicherheitsmaßnahmen unterläßt. Wir sind davon überzeugt, der kostengünstigste Weg, Software zu entwickeln, ist, die Wahrscheinlichkeit zu senken, daß Sicherheitslücken entstehen und die Zeit zwischen der Entstehung der Sicherheitslücke und ihrer Behebung zu minimieren. | ||
+ | |||
+ | Eine wichtige Unterscheidung, die bei der Kostenberechnung gemacht werden muß, ist jene zwischen der Herstellung eines Sicherheitsmechanismus und den Kontrollmaßnahmen für die Richtigkeit und Effektivikät dieser Mechanismen selbst. Zu versuchen, am Ende der Laufzeit noch Vorrichtungen einzubauen, kann schwerwiegende Gestaltungsfragen aufwerfen und wird die Kosten in die Höhe schnellen laßen. Diese Vereinbarung ermutigt, bereits in einem frühen Planungßtadium Entscheidungen bezüglich solcher Mechanismen zu fällen, mit dem Ziel Kosten zu minimieren. Gleichermaßen treibt es die Kosten in die Höhe, wenn man bis kurz vor Bereitstellung der Software an den Kunden mit Kontrollmaßnahmen wie dem Codereview oder dem Penetrationstest wartet. Wir glauben, der beste Weg Sicherheit zu erreichen, ist, sich während der gesamten Laufzeit um Sicherheit zu bemühen. | ||
+ | |||
+ | ===ABER DAS ANFORDERUNGSNIVEAU IST ZU LASCH=== | ||
+ | Diese Vereinbarung geht davon aus, daß die Software, die entwickelt wird, für ein großes Unternehmen oder eine staatliche Behörde ziemlich wichtig ist. Wir haben diese Vereinbarung auf ein Anforderungsniveau gestützt, das von den meisten Softwareentwicklungsorganisationen erreicht werden kann und das die häufigsten Risiken genau bestimmt und behandelt. | ||
+ | |||
+ | Jedoch ist es möglich, daß man das Anforderungsniveau für Software, die in entscheidenden Anwendungen eingesetzt werden wird, anheben möchte. Dies trifft z.B. auf Software aus dem Bereich Medizin-, Finanz- oder Verteidigungswesen zu. Man könnte möglicherweise zusätzliche überprüfungen, Dokumentationen und Versuche anfertigen und durchführen. Man möchte möglicherweise die zum zum Auffinden, Diagnostizieren und Beseitigen von Schwachstellen notwendigen Verfahren verbeßern. Bei weniger sensiblen Anwendungen, könnte man solche Maßnahmen verringern oder entfernen wollen. | ||
+ | |||
+ | ===ABER SO VIEL KÖNNEN WIR NICHT RISKIEREN=== | ||
+ | Dieses Vertragswerk soll Diskußionen darüber, wer das Risiko für Schwachstellen in der Softwaresicherheit auf sich nehmen muß, erleichtern. Am einen Ende der Bandbreite könnte der Kunde alle Risiken tragen während der Entwickler Codes mit einer Menge Schwachstellen liefern könnte. Am anderen Ende könnte der Entwickler alle Risiken auf sich nehmen und die Verantwortung für einen perfekt abgelieferten Code übernehmen. Beide Extreme sind nicht handhabbar. | ||
+ | |||
+ | Gegenwärtig, in diesem Vertragswerk, trägt der Entwickler die Risiken von Problemen, die in den Bestimmungen erfaßt worden sind oder vernünftigerweise von Probeläufen abgedeckt werden sollten. Dennoch muß die Korrektur "neuartiger" Sicherheitsprobleme vom Kunden bezahlt werden. Wir denken, das ist ein zweckmäßiger Ausgleich, denn der Entwickler kann sein Risiko beschränken und ermutigt den Kunden die Sicherheitsanforderungen bereits im Vorfeld korrekt umzusetzen. Viele andere Lösungen für dieses Problem sind möglich. Bitte teilen Sie uns Ihre alternativen Vorschläge mit, damit wir sie in zukünftige Versionen dieses Dokuments einarbeiten können. | ||
+ | |||
+ | Bitte nehmen Sie zur Kenntnis, daß diese Diskußion nur die Risiken, verbunden mit dem Schließen der Sicherheitslücken im Code, abdeckt. Diese Diskußion behandelt ausdrücklich nicht die Kosten, die mit der Entdeckung irgendeines Sicherheitsvorfalls, basierend auf der Ausnutzung solcher Schwachstellen, entstehen. Wir sind an den besten Geschäftsabläufen/ Best Practices auf diesem Gebiet intereßiert. | ||
+ | |||
+ | ===ABER WIE KÖNNEN WIR DEN CODE EINES DRITTEN ABSICHERN...=== | ||
+ | Fast alle Softwareprojekte verwenden in beträchtlichem Umfang Code Dritter, solche wie libraries und frameworks. Dieser Code ist unter dem Aspekt Sicherheit genauso wichtig wie der speziell für Ihr Projekt entwickelte Code des Kunden. Wir glauben, daß die Verantwortung zur Sicherstellung der Sicherheit des Codes am besten vom Entwickler getragen wird, obwohl er möglicherweise nicht in vollem Umfang diese Sicherheit gewährleisten kann. Jedoch muß Sicherheit ein Teil der Build-or-Buy-Entscheidung sein. Das scheint der beste Weg zu sein, den Sicherheitsaspekt zu fördern. | ||
+ | |||
+ | Dem Entwickler ist es selbstverständlich möglich, die Verantwortung bis zum Anbieter der Software des Dritten durchzureichen. Der Entwickler kann die Software des Dritten sogar selbst analysieren oder Sicherheitsexperten engagieren, um sie analysieren zu laßen. | ||
+ | |||
+ | ===ABER WARUM SOLL ICH MIR ALL DIESE MÜHE MACHEN...=== | ||
+ | Schlußendlich glauben wir, daß es keine Alternative dazu gibt, Sicherheit zu einem Thema in den Softwarevertragsverhandlungen zu machen. Momentan sind wir der Meinung, daß im Rahmen von Softwareentwicklungsverträgen, die die Auslieferung von Software zum Ziel haben, ernsthafte Mißverständniße über die Code-Sicherheit auftreten. Das kann nur in teuren Rechtßtreits und Entscheidungen enden, die von Personen mit lediglich wenig Erfahrungen mit oder Verständnis für Software getroffen werden. Eine ausführliche Auseinandersetzung mit diesem Thema können Sie hier nachlesen: Secure software contracting hypothetical case study Secure software contracting hypothetical case study | ||
+ | Aus dem Durcharbeiten dieses Vertrages kann man viel Nutzen ziehen. An erster Stelle werden die Erwartungen zwischen den beteiligten Parteien klar herausgestellt. In einigen Fällen kann dadurch Klagewellen vorgebeugt werden, sobald komplizierte Sicherheitsprobleme in der Software zum Vorschein kommen. Außerdem sind das dieselben Maßnahmen, die aus vielen Gründen im Bereich der Rechtßicherheit und Regelüberwachung gefordert werden. | ||
+ | |||
+ | ===ABER ES IST VIEL ZU MÜHSELIG ALL DAS ZU DOKUMENTIEREN...=== | ||
+ | OWASP animiert nicht zum Dokumentieren um des Dokumentierens Willen. Dieses Vertragswerk wurde darauf ausgerichtet, Qualität zu fördern, nicht Quantität. Wir glauben, eine kurze Risikobewertung, ein paar Seiten mit Anforderungen, ein kurzes Dokument mit dem Sicherheitsentwurf, ein Testplan und einige Testergebniße, würden - bei einigen bestimmten Projekten - einem solchen Vertrag Genüge tun. | ||
Revision as of 14:50, 11 December 2015
OWASP Secure Software Contract Annex (Deutsche Übersetzung)OWASP Ergänzende Vertragsbedingungen zur Entwicklung sicherer Software WARNUNG: DIESES DOKUMENT IST AUSSCHLIESSLICH ALS ORIENTIERUNGSHILFE ANZUSEHEN. OWASP EMPFIEHLT IHNEN DRINGEND EINEN SPEZIALISIERTEN RECHTSANWALT ZUR AUSARBEITUNG EINES SOFTWARELIZENZVERTRAGES HERANZUZIEHEN. EINLEITUNGDiese ergänzende Vertragsvereinbarung soll Softwareentwicklern und ihren Kunden helfen wichtige Vertragslaufzeiten und Vertragsbedingungen bezüglich der Sicherheit von Software, die entwickelt oder geliefert werden soll, zu verhandeln und festzuhalten. Grund für dieses Projekt ist, daß die meisten Verträge keine Vereinbarungen zu diesem Thema enthalten, während die Parteien oftmals jedoch gravierend unterschiedliche Ansichten darüber haben, was tatsächlich vereinbart wurde. Wir glauben, der beste Weg sicherzustellen, daß beiderseits eine sachgerechte Entscheidung über das weitere Vorgehen getroffen wird, ist diese Vertragsbedingungen klar und deutlich auszusprechen. "Die Sicherheit von kommerzieller Software wird sich verbeßern, wenn der Markt bessere Sicherheit fordert. Jede Angebotsanfrage für Software sollte an die Anbieter wenigstens die Frage enthalten, wie sie ihre Produkte auf Schwachstellen hin überprüfen. Diese Maßnahme wird ein erster Schritt sein Anbieter von Software 'von der Stange' und ausgegliederten Entwicklern davon zu überzeugen, daß Unternehmen Sicherheit wertschätzen." -- John Pescatore, Forschungsdirektor bei Gartner Wir halten Kunden und Entwickler an, dieses Dokument als ein Rahmenkonzept für die Diskußion von Erwartungen und Verhandlung von Haftungsfragen zu nutzen. Diese ergänzenden Vertragsbedingungen sind dafür vorgesehen, einem Vertrag über die Entwicklung von Software beigefügt zu werden. Diese Bedingungen sind verhandlungsfähig, d.h. sie können und sollten von Kunden und Entwicklern erörtert werden. ÜBER DAS PROJEKTDieses Dokument wurde von der Open Web Application Security Project Stiftung (kurz: OWASP) erstellt. Die Stiftung ist eine gemeinnützige Organisation, die sich der Entwicklung freier und öffentlich zugänglicher Werkzeuge sowie der Dokumentation hinsichtlich sicherer Software gewidmet hat. Um den einfachen Gebrauch dieses Dokuments bei privaten Vertragßchlüßen zu erleichtern, wird es unter der CC Share Alike 3.0 license zur Verfügung gestellt. Sie können es anpaßen und verwenden, wie es Ihren Bedürfnißen entspricht. Ergänzende Details zu diesem Projekt können sie unter http://www.owasp.com/index.php/OWASP_Legal_Project aufrufen. Wir begrüßen Rückmeldungen sowohl seitens Softwareherstellern sowie - verbrauchern als auch seitens der Rechtskreise. OWASP möchte sich an dieser Stelle ausdrücklich vielmals für die umfaßende Unterstützung durch Aspect Security während der Recherche und Vorbereitung für dieses Dokuments bedanken. EINWÄNDEDie folgenden Seiten behandeln oft eingeführte Einwände gegen die Nutzung dieser Formulierungen in Zusammenhang mit Softwareentwicklungsverträgen ABER NICHT ALLE BESTIMMUNGEN TREFFEN AUF UNS ZU...Dieses Dokument sollte als Ausgangspunkt Ihres Vertrages angesehen werden. Möglicherweise gefallen Ihnen nicht alle Maßnahmen oder Sie wollen Ihrem Vertragspartner mehr vorschlagen. Vielleicht wollen Sie Haftungsfragen anders regeln. Dieses Dokument beabsichtigt nicht exakt die Bedürfniße jedes einzelnen Softwarekunden und Softwareentwicklers aufzugreifen. Es beabsichtigt vielmehr ein Rahmenkonzept bereitzustellen, an Hand deßen die Schlüßelthemen diskutiert werden können, die maßgeblich sind, um sicherzustellen, daß am Ende eine sichere Software herauskommt. Nach Ihrem Gespräch über die Softwaresicherheit und dem Treffen einer Vereinbarung, sollten Sie diese auf sich maßschneidern. ABER WER SOLL FÜR DIESE MAßNAHMEN ZAHLEN...Bei diesem Vertrag geht es NICHT darum, den Softwareentwickler mehr zu belasten. Es stellt sich nicht die Frage, ob Sicherheit mit Kosten einhergeht - natürlich, lautet die Antwort. Die beßere Frage lautet eher, welche Maßnahmen beide Parteien ergreifen sollten, um diese Kosten zu senken und zu welchem Zeitpunkt. Diese ergänzenden Vertragsbedingungen schweigen bewußt darüber, wer die Kosten dieser Maßnahmen tragen sollte. Während viele dieser Maßnahmen bereits greifen sollten, was auch von vielen Kunden erwartet wird, werden sie nicht regelmäßig von der Industrie angewandt. Die Frage danach, wer (und wie viel) zahlt, sollte Gegenstand der Verhandlung sein. Kosten für Sicherheitsmaßnahmen zu berechnen, ist sehr schwierig. Einerseits gibt es Kosten, die auf der Ausführung von Sicherheitsmaßnahmen beruhen und andererseits entstehen erhebliche Kosten erst, wenn man Sicherheitsmaßnahmen unterläßt. Wir sind davon überzeugt, der kostengünstigste Weg, Software zu entwickeln, ist, die Wahrscheinlichkeit zu senken, daß Sicherheitslücken entstehen und die Zeit zwischen der Entstehung der Sicherheitslücke und ihrer Behebung zu minimieren. Eine wichtige Unterscheidung, die bei der Kostenberechnung gemacht werden muß, ist jene zwischen der Herstellung eines Sicherheitsmechanismus und den Kontrollmaßnahmen für die Richtigkeit und Effektivikät dieser Mechanismen selbst. Zu versuchen, am Ende der Laufzeit noch Vorrichtungen einzubauen, kann schwerwiegende Gestaltungsfragen aufwerfen und wird die Kosten in die Höhe schnellen laßen. Diese Vereinbarung ermutigt, bereits in einem frühen Planungßtadium Entscheidungen bezüglich solcher Mechanismen zu fällen, mit dem Ziel Kosten zu minimieren. Gleichermaßen treibt es die Kosten in die Höhe, wenn man bis kurz vor Bereitstellung der Software an den Kunden mit Kontrollmaßnahmen wie dem Codereview oder dem Penetrationstest wartet. Wir glauben, der beste Weg Sicherheit zu erreichen, ist, sich während der gesamten Laufzeit um Sicherheit zu bemühen. ABER DAS ANFORDERUNGSNIVEAU IST ZU LASCHDiese Vereinbarung geht davon aus, daß die Software, die entwickelt wird, für ein großes Unternehmen oder eine staatliche Behörde ziemlich wichtig ist. Wir haben diese Vereinbarung auf ein Anforderungsniveau gestützt, das von den meisten Softwareentwicklungsorganisationen erreicht werden kann und das die häufigsten Risiken genau bestimmt und behandelt. Jedoch ist es möglich, daß man das Anforderungsniveau für Software, die in entscheidenden Anwendungen eingesetzt werden wird, anheben möchte. Dies trifft z.B. auf Software aus dem Bereich Medizin-, Finanz- oder Verteidigungswesen zu. Man könnte möglicherweise zusätzliche überprüfungen, Dokumentationen und Versuche anfertigen und durchführen. Man möchte möglicherweise die zum zum Auffinden, Diagnostizieren und Beseitigen von Schwachstellen notwendigen Verfahren verbeßern. Bei weniger sensiblen Anwendungen, könnte man solche Maßnahmen verringern oder entfernen wollen. ABER SO VIEL KÖNNEN WIR NICHT RISKIERENDieses Vertragswerk soll Diskußionen darüber, wer das Risiko für Schwachstellen in der Softwaresicherheit auf sich nehmen muß, erleichtern. Am einen Ende der Bandbreite könnte der Kunde alle Risiken tragen während der Entwickler Codes mit einer Menge Schwachstellen liefern könnte. Am anderen Ende könnte der Entwickler alle Risiken auf sich nehmen und die Verantwortung für einen perfekt abgelieferten Code übernehmen. Beide Extreme sind nicht handhabbar. Gegenwärtig, in diesem Vertragswerk, trägt der Entwickler die Risiken von Problemen, die in den Bestimmungen erfaßt worden sind oder vernünftigerweise von Probeläufen abgedeckt werden sollten. Dennoch muß die Korrektur "neuartiger" Sicherheitsprobleme vom Kunden bezahlt werden. Wir denken, das ist ein zweckmäßiger Ausgleich, denn der Entwickler kann sein Risiko beschränken und ermutigt den Kunden die Sicherheitsanforderungen bereits im Vorfeld korrekt umzusetzen. Viele andere Lösungen für dieses Problem sind möglich. Bitte teilen Sie uns Ihre alternativen Vorschläge mit, damit wir sie in zukünftige Versionen dieses Dokuments einarbeiten können. Bitte nehmen Sie zur Kenntnis, daß diese Diskußion nur die Risiken, verbunden mit dem Schließen der Sicherheitslücken im Code, abdeckt. Diese Diskußion behandelt ausdrücklich nicht die Kosten, die mit der Entdeckung irgendeines Sicherheitsvorfalls, basierend auf der Ausnutzung solcher Schwachstellen, entstehen. Wir sind an den besten Geschäftsabläufen/ Best Practices auf diesem Gebiet intereßiert. ABER WIE KÖNNEN WIR DEN CODE EINES DRITTEN ABSICHERN...Fast alle Softwareprojekte verwenden in beträchtlichem Umfang Code Dritter, solche wie libraries und frameworks. Dieser Code ist unter dem Aspekt Sicherheit genauso wichtig wie der speziell für Ihr Projekt entwickelte Code des Kunden. Wir glauben, daß die Verantwortung zur Sicherstellung der Sicherheit des Codes am besten vom Entwickler getragen wird, obwohl er möglicherweise nicht in vollem Umfang diese Sicherheit gewährleisten kann. Jedoch muß Sicherheit ein Teil der Build-or-Buy-Entscheidung sein. Das scheint der beste Weg zu sein, den Sicherheitsaspekt zu fördern. Dem Entwickler ist es selbstverständlich möglich, die Verantwortung bis zum Anbieter der Software des Dritten durchzureichen. Der Entwickler kann die Software des Dritten sogar selbst analysieren oder Sicherheitsexperten engagieren, um sie analysieren zu laßen. ABER WARUM SOLL ICH MIR ALL DIESE MÜHE MACHEN...Schlußendlich glauben wir, daß es keine Alternative dazu gibt, Sicherheit zu einem Thema in den Softwarevertragsverhandlungen zu machen. Momentan sind wir der Meinung, daß im Rahmen von Softwareentwicklungsverträgen, die die Auslieferung von Software zum Ziel haben, ernsthafte Mißverständniße über die Code-Sicherheit auftreten. Das kann nur in teuren Rechtßtreits und Entscheidungen enden, die von Personen mit lediglich wenig Erfahrungen mit oder Verständnis für Software getroffen werden. Eine ausführliche Auseinandersetzung mit diesem Thema können Sie hier nachlesen: Secure software contracting hypothetical case study Secure software contracting hypothetical case study Aus dem Durcharbeiten dieses Vertrages kann man viel Nutzen ziehen. An erster Stelle werden die Erwartungen zwischen den beteiligten Parteien klar herausgestellt. In einigen Fällen kann dadurch Klagewellen vorgebeugt werden, sobald komplizierte Sicherheitsprobleme in der Software zum Vorschein kommen. Außerdem sind das dieselben Maßnahmen, die aus vielen Gründen im Bereich der Rechtßicherheit und Regelüberwachung gefordert werden. ABER ES IST VIEL ZU MÜHSELIG ALL DAS ZU DOKUMENTIEREN...OWASP animiert nicht zum Dokumentieren um des Dokumentierens Willen. Dieses Vertragswerk wurde darauf ausgerichtet, Qualität zu fördern, nicht Quantität. Wir glauben, eine kurze Risikobewertung, ein paar Seiten mit Anforderungen, ein kurzes Dokument mit dem Sicherheitsentwurf, ein Testplan und einige Testergebniße, würden - bei einigen bestimmten Projekten - einem solchen Vertrag Genüge tun.
FOOWhat is OWASP Security Principles Project?Here you should add a short description of what your project actually does. What is the primary goal of your project, and why is it important? The end goal is to identify, cite, and document the fundamental principles of information security. Once this is well organised, I think it would be great to publish this through the OWASP Press. Of course, it will always remain freely available, and any money collected will go directly into the project to absorb costs with any remaining funds going to the OWASP Foundation. This document should serve as a guide to technical architects and designers outlining the fundamental principles of security. PresentationThis is where you can link to slide presentations related to your project.
Project LeaderA project leader is the individual who decides to lead the project throughout its lifecycle. The project leader is responsible for communicating the project’s progress to the OWASP Foundation, and he/she is ultimately responsible for the project’s deliverables. The project leader must provide OWASP with his/her real name and contact e-mail address for his/her project application to be accepted, as OWASP prides itself on the openness of its products, operations, and members.
Related ProjectsThis is where you can link to other OWASP Projects that are similar to yours. Openhub |
Quick DownloadThis is where you can link to your repository. The home of the OWASP Security Principles is on GitHub. You are encourged to fork, edit and push your changes back to the project through git or edit the project directly on github. However, if you like you may also download the master repository from the following links: News and EventsThis is where you can link to press your project has been a part of. Appropriate press includes: Project Leader interviews, articles written about your project, and videos about your project.
In PrintThis is where you place links to where your project product can be downloaded or purchased, in the case of a book. This project can be purchased as a print on demand book from Lulu.com ClassificationsHere is where you can let the community know what project stage your project is currently in, whether the project is a builder, breaker, or defender project, and what type of project you are running. |
Many projects have "Frequently Asked Questions" documents or pages. However, the point of such a document is not the questions. The point of a document like this are the answers. The document contains the answers that people would otherwise find themselves giving over and over again. The idea is that rather than laboriously compose and post the same answers repeatedly, people can refer to this page with pre-prepared answers. Use this space to communicate your projects 'Frequent Answers.'
How can I participate in your project?
All you have to do is make the Project Leader's aware of your available time to contribute to the project. It is also important to let the Leader's know how you would like to contribute and pitch in to help the project meet it's goals and milestones. There are many different ways you can contribute to an OWASP Project, but communication with the leads is key.
If I am not a programmer can I participate in your project?
Yes, you can certainly participate in the project if you are not a programmer or technical. The project needs different skills and expertise and different times during its development. Currently, we are looking for researchers, writers, graphic designers, and a project administrator.
Contributors
The success of OWASP is due to a community of enthusiasts and contributors that work to make our projects great. This is also true for the success of your project. Be sure to give credit where credit is due, no matter how small! This should be a brief list of the most amazing people involved in your project. Be sure to provide a link to a complete list of all the amazing people in your project's community as well.
The OWASP Security Principles project is developed by a worldwide team of volunteers. A live update of project contributors is found here.
The first contributors to the project were:
- Dennis Groves
- YOUR NAME BELONGS HERE
A project roadmap is the envisioned plan for the project. The purpose of the roadmap is to help others understand where the project is going. It gives the community a chance to understand the context and the vision for the goal of the project. Additionally, if a project becomes inactive, or if the project is abandoned, a roadmap can help ensure a project can be adopted and continued under new leadership.
Roadmaps vary in detail from a broad outline to a fully detailed project charter. Generally speaking, projects with detailed roadmaps have tended to develop into successful projects. Some details that leaders may consider placing in the roadmap include: envisioned milestones, planned feature enhancements, essential conditions, project assumptions, development timelines, etc. You are required to have at least 4 milestones for every year the project is active.
As of October 2013, the priorities are:
- Finish the referencing for each principle.
- Update the Project Template.
- Use the OWASP Press to develop a book.
- Finish and publish the book on Lulu.
Involvement in the development and promotion of the OWASP Security Principles Project is actively encouraged! You do not have to be a security expert in order to contribute. Some of the ways you can help:
- Helping find references to some of the principles.
- Project administration support.
- Wiki editing support.
- Writing support for the book.
PROJECT INFO What does this OWASP project offer you? |
RELEASE(S) INFO What releases are available for this project? | |||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|