Skip to content

Roadmap for 2019-2020 #148

@UlisesGascon

Description

@UlisesGascon

Hi all!

In the last months we were focus on improve the codebase with tests, mostly e2e test and CI.

Now we are more confidents on the source code and it's easier to validate PRs and merge new contributions. I think is a good time to discuss about the roadmap for NodeGoat in the following months.

Right now we are close to publish release 1.4 that includes (e2e and ci). I just want to suggest some possible targets for the following releases.

Release 1.5

Main goal:

  • Improve source code

Pending PRs (Update/review):

Targets:

Release 1.6

Main goal:

  • Refresh to OWASP 2019
  • Let's refresh the technology that we use 💪

Targets:

Open Questions && Discussions

Main goals/ideas suggested by @ckarande:

Honestly, I didn't find certain new additions to OWASP top 10 2017 very relevant to Node.js usage (e.g, not many Node.js users deal with XML) but in the sprit of demonstrating the top 10, it could be worth explaining / incorporating the latest OWASP top 10 list. I would like to retain some of the existing vulnerabilities from the OWASP Top 10 2013 version that are not in the 2017 version (such as CSRF, Insecure Redirects, etc) . So we can make two sections on the tutorial site - OWASP Top 10 2017, and Beyond OWASP Top 10.

  • Provide versions that are close to real world Node.js usage

As you may know, current version of Nodegoat uses templates for rendering UI and cookie based stateful session. This architecture is good for beginners to have the least resistance to start diving into the security specific concepts. However, I would like to provide two additional versions of NodeGoat that are close to real world Node.js apps and demonstrate security vulnerabilities in the context of these architectures:

If we have a clear roadmap it will super easy to reclute contributors and provide them a clear path to follow :-)

I will try to setup a local Hackathon in Madrid to reclute new contributors and close some issues 👍

In order to keep all smooth and simple to review, I will suggest to work using issues per feature and link those issues to small PRs and commit using GitFlow (branches per release) so we can concentrate all the PRs per release. And then a final PR from the release branch to the master in order to upgrade package version and deploy in Heroku.

What do you think? Do you agree for the targets/items for release 1.5? I think that we need to discuss a lot for 1.6 as now it is very conceptual

Metadata

Metadata

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions