SimpleRisk was written by Josh Sokol who has a background in Information Security and served as a Board member of the OWASP Foundation from 1/1/2014 to 12/31/2017.  He has been involved in the application security community for over a decade.  SimpleRisk was built initially for his personal use running the Security Program at National Instruments, and it was built to his security standards.

Secure Application Development

Here are some of the things that we do in order to ensure the security of the code we are writing:

  • Input Validation: This is the process of using regular expressions and static type casting to ensure that inputs coming from the user are appropriate and do not cause bugs or security issues.
  • HTML Output Encoding: This ensures that data rendered into the user's browser is treated as text on the page and not code to be executed.
  • Parameterized Database Queries: This ensures that the application is validating the length and type of content that is being passed into SQL queries in order to prevent SQL injection (SQLi) attacks.
  • Hashed and Salted Passwords: We do not store clear-text passwords in the SimpleRisk database and use unique "salts" to prevent rainbow table attacks if the password database is ever stolen.
  • Cross-Site Request Forgery (CSRF) Nonces: Random parameters are inserted into GET and POST requests in order to prevent attackers from being able to force users to make requests on their behalf.

Security Validation

SimpleRisk runs a private Bug Bounty program with HackerOne.  While we do not control the testing cycles in which our code is tested for vulnerabilities, we do leverage this resource for continual testing.  We also have a public Responsible Disclosure Policy for responsible disclosures of issues that others may find with SimpleRisk.  We also use static analysis tools to look for vulnerabilities in the code and have many companies and individuals testing it on a regular basis.  If you look at the demo site, as an example, you will see many failed attempts at XSS and SQLi attacks against the application.

Past Security Issues

To date, we have had only one CVE issued against the product, and it was in our very early days against a newly implemented bit of functionality.  Since then, we have been hyper-paranoid to not let that happen again.