Skip to content

Latest commit

 

History

History
124 lines (91 loc) · 6.25 KB

README.md

File metadata and controls

124 lines (91 loc) · 6.25 KB

Code style: black GitHub Super-Linter Main Branch Build

Issues
PR's Welcome GitHub contributors GitHub last commit GitHub commit activity

Open in GitHub Codespaces

Common Requirements Enumeration Application

See the application working and more explanation at https://www.opencre.org CRE is an interactive content linking platform for uniting security standards and guidelines. It offers easy and robust access to relevant information when designing, developing, testing and procuring secure software. This python web and cli application handles adding and presenting CREs.

WHY?

Independent software security professionals got together to find a solution for the complexity and fragmentation in today’s landscape of security standards and guidelines. These people are Spyros Gasteratos, Rob van der Veer and friends, in close collaboration with the SKF, OpenSSF and Owasp Top 10 project.

HOW?

The CRE links each section of a standard to a shared topic (a Common Requirement), causing that section to also link with all other resources that map to the same topic. This 1) enables users to find all combined information from relevant sources, 2) it facilitates a shared and better understanding of cyber security, and 3) it allows standard makers to have links that keep working and offer all the information that readers need, so they don’t have to cover it all themselves. The CRE maintains itself: topic links in the standard text are scanned automatically. Furthermore, topics are linked with related other topics, creating a semantic web for security.

Example: the session time-out topic will take the user to relevant criteria in several standards, and to testing guides, development tips, more technical detail, threat descriptions, articles etc. From there, the user can navigate to resources about session management in general.

Some of the data has been kindly contributed by the SKF and ASVS projects

Running

Locally

Docker

The easiest way to run OpenCRE locally is by running the published docker container. You can do so by running: docker run -p 5000:5000 ghcr.io/owasp/opencre/opencre:latest After the container has finished downloading the remote information you can access it in localhost

Command Line

To run outside of Docker you need to install OpenCRE. To install this application you need python3, yarn and virtualenv.

  • Clone the repository:
git clone https://github.com/OWASP/common-requirement-enumeration 
  • Install dependencies
 make install 
  • Download the latest CRE graph from upstream by running
python cre.py --upstream_sync

Keep in mind that until Issue #534 is fixed you won't have access to gap analysis results locally

To run the CLI application, you can run

python cre.py --help

To download a remote cre spreadsheet locally you can run

python cre.py --review --from_spreadsheet < google sheets url>

To add a remote spreadsheet to your local database you can run

python cre.py --add --from_spreadsheet < google sheets url>

To run the web application for development you can run

$ make start-containers
$ make start-worker 

# in a seperate shell
$ make dev-flask

Alternatively, you can use the dockerfile with

make docker && make docker-run

Some features like Gap Analysis require a neo4j DB running, you can start this with

make docker-neo4j

enviroment varaibles for app to connect to neo4jDB (default):

  • NEO4J_URL (neo4j//neo4j:password@localhost:7687)

To run the web application for production you need gunicorn and you can run from within the cre_sync dir

make prod-run

Docker

You can build the production or the development docker images with make docker-prod and make docker-dev respectively The environment variables used by OpenCRE are:

        - name: NEO4J_URL
        - name: NO_GEN_EMBEDDINGS
        - name: FLASK_CONFIG
        - name: DEV_DATABASE_URL
        - name: INSECURE_REQUESTS # development or TLS terminated environments only
        - name: REDIS_HOST
        - name: REDIS_PORT
        - name: REDIS_NO_SSL
        - name: REDIS_URL # in case REDIS_HOST and REDIS_PORT are unavailable
        - name: GCP_NATIVE # if there are ambient GCP credentials, only useful for VERTEX chatbot
        - name: GOOGLE_SECRET_JSON # if not running on GCP
        - name: GOOGLE_CLIENT_ID # useful for login only
        - name: GOOGLE_CLIENT_SECRET # useful for login only
        - name: LOGIN_ALLOWED_DOMAINS # useful for login only
        - name: OpenCRE_gspread_Auth # useful only when importing data, possible values 'oauth' or 'service_account'

You can run the containers with make docker-prod-run and make-docker-dev-run

Developing

You can run backend tests with

make test

You can run get a coverage report with

make cover

Try to keep the coverage above 70%

Contributing

Please see Contributing for contributing instructions

Roadmap

For a roadmap of what we would like to be done please see the issues.