Are you still working on this?

[mannyhenri]

Very interested in this plugin but is it possible you're not maintaining it anymore since the acquisition? ESLINT in my opinion is probably the best approach to write implement best practices around writing secured code.

If you're not maintaining it anymore would you be open to transfer this project to me? I'd like to keep it alive and update it with other rules.

[jesusprubio]

Same here, are you still working on it? I would like to keep contributing. A "npm audit-code" or something similar would be awesome :)

[mannyhenri]

@jesusprubio if we don't get an answer back let's fork this and keep it alive somewhere else...

[jesusprubio]

Sure, but lets give them some days, it's Sunday today :). I have more rules and some ideas implemented locally, like support for rules to check the absence of stuff (instead the presence).

[mannyhenri]

@jesusprubio of course can't wait to see what you came up with.

[mannyhenri]

@jesusprubio just got word from the NPM team that our best option is to fork and work on it ourselves. So I'll fork it and invite you, works for you?

[mannyhenri]

@evilpacket if we send you updates in ESLINT rules for this are you still looking into maintaining and updating it with new rules? I'm building a secured based template for @BedRock4 and want to leverage ESLINT rules to instill security best practices.

[trycrmr]

Opened this topic on npm.community: https://npm.community/t/what-are-the-plans-for-eslint-plugin-security/1615

[amazzoccone]

Topic was closed 😞.

[evilpacket]

Yup I’ll accept pr’s! would be good for some updates to rules. Happy to give maintainership as well as needed as I can’t always get to things.

…

On Wed, Jun 13, 2018 at 5:25 AM Manny Henri ***@***.***> wrote: @evilpacket <https://github.com/evilpacket> if we send you updates in ESLINT rules for this are you still looking into maintaining and updating it with new rules? I'm building a secured based template for @BedRock4 <https://github.com/BedRock4> and want to leverage ESLINT rules to instill security best practices. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHEOY-PkA6Wa0Qcp8s5XfshyWQWcZHjks5t8QSfgaJpZM4UhrXL> .

[MVrachev]

Is there an active fork of this project somewhere?
Because there is no response from @evilpacket again...
I have been searching for an active fork but there is none.

[webschik]

@MVrachev, I support a version for TSLint - https://github.com/webschik/tslint-config-security, if you're interested.

[MVrachev]

Wow, awesome! Thank you @webschik! I will have a look.

[kewilson]

So is this going to be maintained? If not has anyone found a suitable drop-in replacement? I'd also pony up time for being a maintainer to keep the repo alive and well going forward if there are no suitable replacements.

[MVrachev]

I found one replacement - https://github.com/webschik/tslint-config-security.
That's a TSLint plugin. TSLint scans TypeScript files the same as ESLint does.

Because TypeScript is a superset of JavaScript TSLint can use its rules upon JavaScript files after configuration.

First, you need to install TSLint and configure it.
Here is an example configuration to scan JavaScript files with the plugin above:

tslint.json:

{
    "extends": ["tslint-config-security"],
    "jsRules": {
      "tsr-detect-buffer-noassert": [true],
      "tsr-detect-child-process": [true],
      "tsr-detect-eval-with-expression": [true],
      "tsr-detect-no-csrf-before-method-override": [true],
      "tsr-detect-non-literal-buffer": [true],
      "tsr-detect-non-literal-fs-filename": [true],
      "tsr-detect-non-literal-regexp": [true],
      "tsr-detect-non-literal-require": [true],
      "tsr-detect-possible-timing-attacks": [true],
      "tsr-detect-pseudo-random-bytes": [true],
      "tsr-detect-unsafe-regexp": [true],
      "tsr-disable-mustache-escape": [true],
      "tsr-detect-html-injection": [true],
      "tsr-detect-sql-literal-injection": [true],
      "tsr-detect-unsafe-cross-origin-communication": [true],
      "tsr-detect-unsafe-properties-access": [true]
  }
}

and if you want to use the --project option on the command line to scan your whole project you can add the following into your tsconfig.json:

{
  "compilerOptions": {
    "strict": true,
    "allowJs": true
  },
  "include": [
    "./**/*"
  ],
  "exclude":[
    "node_modules",
  ]
}

The "allowJs" flag is important here.

[evilpacket]

I'd like to get some maintenance going on this again. I'm bad at open source and would welcome in some maintainers to assist. I'm on PTO this week and if I get a few hours here or there I plan to follow up on some of the PR's and issues.

If you would like to help maintain I'd like to chat.

[Berkmann18]

I'm down for helping in maintaining this package.

[codymikol]

Let me know how I can help out :)

[pdehaan]

@evilpacket Is the contents of blog.liftsecurity.io still available somewhere (or do we have to use archive.org to try and scrape the cached content)?
It'd be nice to put the docs along with the rules instead of having to rely on archive.org links.

[evilpacket]

@pdehaan yes all the markdown files are still available but it's a private repo. Let's coordinate this via #34

[UziTech]

@evilpacket are you still looking for maintainers for this repo?

[gkouziik]

@evilpacket are you still looking for maintainers for this repo?

@UziTech I am looking for maintainers for my repo eslint-plugin-security-node is the package name in npm.

[UziTech]

@gkouziik is that a fork of this package?

[gkouziik]

@UziTech No its not a fork, they just have some similar rules

[UziTech]

@gkouziik I would be willing to help maintain it.

[rfm-bot]

🚧 Is this repo looking for support?
Hello, we created this issue becuase the user @UziTech told us you are calling for maintainers.
✅ If you're looking for collaborators no action is required.
👮🏻‍♂️ If this repo is well-supported please put a comment here sospedra/rfm#69 and we'll close it immediately.
Sorry for any inconvinience. We understand this message can feel spammy but we really think is good to double-check first with the current owners :)

[nzakas]

See #71.