Difference between revisions of "Category:OWASP Honeycomb Project"

Jump to: navigation, search
m (Background: Another small grammar correction)
Line 14: Line 14:
* [[:Category:Principle|Principles]]
* [[:Category:Principle|Principles]]
* [[:Category:Threat|Threats]]
* [[:Category:Threat_Agent|Threats]]
* [[:Category:Vulnerability|Vulnerabilities]]
* [[:Category:Vulnerability|Vulnerabilities]]
* [[:Category:Attack|Attacks]]
* [[:Category:Attack|Attacks]]
* [[:Category:Countermeasure|Countermeasures]].
* [[:Category:Countermeasure|Countermeasures]]
* [[:Category:Category:Technical_impact|Technical Impacts]]
* [[:Category:Category:Business_impact|Business Impacts]]
Each of these categories may have subcategories. For example, there is a general [[:Category:Vulnerability|Vulnerability]] category for all articles describing a vulnerability. There are also tags for more specific types of vulnerabilities, such as those listed below:
Each of these categories may have subcategories. For example, there is a general [[:Category:Vulnerability|Vulnerability]] category for all articles describing a vulnerability. There are also tags for more specific types of vulnerabilities, such as those listed below:

Revision as of 05:06, 1 February 2008


In the Honeycomb project, OWASP is assembling the most comprehensive and integrated guide ever attempted to the fundamental building blocks of application security (principles, threats, attacks, vulnerabilities, and countermeasures) through collaborative community efforts.

OWASP has been steadily plugging away at this problem since 2000, across projects like VulnXML, WAS-XML, Top Ten, WebScarab, WebGoat, Testing Project, Guide, and others. At the same time, OWASP members have been hard at work securing the most important applications in the world. We're trying to bring our practical experience to this difficult area.

Although there is already a wealth of information here, we are just starting on this project. We need volunteers to help us complete articles, categorize articles appropriately, eliminate duplication, and more. You can view the OWASP Honeycomb Project Roadmap to find out what is being worked on and how you can help.


Application security information cannot be organized into a one-dimensional taxonomy. We've adopted the folksonomy tagging approach to solving this problem. We simply tag our articles with a number of different categories. You can use these categories to help get different views into the complex, interconnected set of topics that is application security.

The tagging scheme does have a simple hierarchy, though. The top level categories are:

Each of these categories may have subcategories. For example, there is a general Vulnerability category for all articles describing a vulnerability. There are also tags for more specific types of vulnerabilities, such as those listed below:


What we are trying to accomplish?

Our basic assumption is that we will never be able to make progress in application security without some basic building blocks. We've identified principles, threats, vulnerabilities, attacks, and countermeasures as the fundamentals to most application security activities. So we've set out to capture all the common names used in these areas, gather as much information as we can about each, and interlink them in a meaningful way.

The difficulties in organizing this information

Most efforts to organization application security information attempt to force the information into a one-dimensional taxonomy of one sort or another. These efforts (including the OWASP Top Ten) have failed to adequately make the information useful. Attempting to simplify application security into a one-dimensional taxonomy makes the information useless for many critical tasks.

The approach we’ve taken

We've decided to apply the 'folksonomy' approach popularized recently to organize information with many complex relationships. So each of the major types of building blocks has its own 'tag' (called a 'category' in MediaWiki). This organizes the basic types of articles. Then within each article, we have references to other related articles, so that it is possible to explore the information set.

Why the name Honeycomb?

We are trying to use a distributed, self-organizing approach to create something beyond any of the individuals involved. Honeycombs are spontaneously formed in nature from the complex interaction of simple elements. See http://www.sciencedaily.com/releases/2006/08/060818014819.htm.

How to use the information?

We're not sure all the ways that this information might be used. But we're sure that having all the pieces defined and knowing how they fit together will help.

  • Architects may want to use this information when threat modeling their applications. You'll want to identify combinations of threats, attacks, and vulnerabilities that apply to your system. Then you should select appropriate countermeasures and use the principles to help guide design decisions.
  • Deveopers may want to use this information to learn about different vulnerabilities and to select coding guidelines for their project.
  • Security researchers may want to use this framework to organize their thinking about security and help to ensure completeness.

Related Projects

The Common Weakness Enumeration (CWE) project at Mitre is a formal list of software weaknesses created to serve as a common language for describing software security weaknesses in architecture, design, or code; serve as a standard measuring stick for software security tools targeting these weaknesses; and provide a common baseline standard for weakness identification, mitigation, and prevention efforts.

The Software Assurance Metrics and Tool Evaluation (SAMATE) project from NIST "supports the Department of Homeland Security's Software Assurance Tools and R&D Requirements Identification Program. The objective of part 3, Technology (Tools and Requirements) is the identification, enhancement and development of software assurance tools. NIST is leading in (A) testing software evaluation tools, (B) measuring the effectiveness of tools, and (C) identifying gaps in tools and methods."

Volunteers Needed

Our current tactical goals are:

  • Fill in the contents of the stub honeycomb articles (those marked with {{Template:Stub}})
  • Refine the contents and structure of the honeycomb articles
  • Eliminate redundancy in the articles and categories

The following tasks are ready for volunteers:

  • Merge "Buffer overflow", "Buffer Overflow" and related redundant articles
  • Merge "Cross Site Scripting" and "Cross-site_scripting"
  • Merge "SQL Injection" and "SQL injection"

To find out more about what you can help, please go to OWASP Honeycomb Project Roadmap.

Feedback and Participation:

We hope you find the OWASP Honeycomb Project useful. Please contribute to the Project by volunteering for one of the Tasks, sending your comments, questions, and suggestions to owasp@owasp.org. To join the OWASP Honeycomb Project mailing list or view the archives, please visit the subscription page.


Listed on the pages below are all the articles that are a part of the Honeycomb project. It is interesting to browse, but it is just an unstructured alphabetical list. All the articles are tagged with various categories that are a part of this project to help you find the article you're looking for.

Note: the portal only lists categories that start with the letters of the first 200 articles. To view other categories, select the "next 200" button.

[[Category:OWASP Honeycomb Project


This category has the following 9 subcategories, out of 9 total.


C cont.



Pages in category "OWASP Honeycomb Project"

This category contains only the following page.