Live data from Hacker News

Launch HN: Datree (YC W20) – Best practices and security policies on each commit

news.ycombinator.com

41–50 of 54 posts

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#41
post #15

Wondering if there any open source project which does similar things? (surprised if it's not)

you will need to glue together (and maintain) a bunch of different open-source projects to achieve the same capabilities - here are some: https://github.com/danger/danger-js, https://github.com/probot/probot, https://github.com/Yelp/detect-secrets, https://github.com/github/licensed, and many more...

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#42
This is really awesome! One area I'd recommend looking into is automated scanning of cloud infrastructure templates (Terraform, CloudFormation, Troposphere, ARM Templates, etc.) These get pushed to source control all the time and often contain tons of policy violations.

The pricing feels a bit steep, especially considering that it's 3.5x the cost per user of GitHub itself ($8 vs $28) but I suppose most enterprises wouldn't mind at their scale compared to the cost of a breach.

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#43

This is really awesome! One area I'd recommend looking into is automated scanning of cloud infrastructure templates (Terraform, CloudFormation, Troposphere, ARM Templates, etc.) These get pushed to source control all the time and often contain tons of policy violations. The pricing feels a bit steep, especially considering that it's 3.5x the cost per user of GitHub itself ($8 vs $28) but I suppose most enterprises wo…

We do support Terraform, CloudFormation and ARM Templates because those are all structured files. Unlike your source control, we are doing heavy compute processing every time a new PR created, so our costs are higher...

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#44
post #29

>What we built is a rules engine, which is essentially a server-side git-hook platform. Isn't it too late once it is committed to github? It seems like this would be much more useful as a service running as a precommit hook on each workstation. Probably harder to ship/monetize that but as far as actually solving the problem wouldn't that be better?

Initially, we started as a CLI tool, but as you said, it is part of the problem, how do you make sure all of your developers are using the CLI/pre-commit hooks? This is why we choose to integrate on the pull-request level. It is not perfect, but at least your plain text secrets will not be merged into master and go in onto your developer's laptops and your servers(less). :) We try to find a balance between perfect an…

But it’s already in the git objects and therefore accessible to anyone who clones the repository? I am not 100% sure about that. Can someone confirm?

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#45
post #15

Wondering if there any open source project which does similar things? (surprised if it's not)

I developed this a while ago and it was used as gate check in a Linux Foundation project. Its essentially the same as the OP project (regex based), but without the GUI.

https://anteater.github.io/

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#46
post #29

Earlier quoted context omitted.

Initially, we started as a CLI tool, but as you said, it is part of the problem, how do you make sure all of your developers are using the CLI/pre-commit hooks? This is why we choose to integrate on the pull-request level. It is not perfect, but at least your plain text secrets will not be merged into master and go in onto your developer's laptops and your servers(less). :) We try to find a balance between perfect an…

But it’s already in the git objects and therefore accessible to anyone who clones the repository? I am not 100% sure about that. Can someone confirm?

We educate our customers on how to delete the branch and remove it from history: https://docs.datree.io/docs/do-not-include-secret-files

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#48
post #37

Looks good. We were trying to implement this using a mix of CI, pre-commit hooks and Gitlab PR templates, but it was limiting. This looks like exactly what we needed. Regarding custom rules, does the tool run automated tests for those too?

just to clarify, Datree runs automatic checks for each custom rule that a user creates

We have a Java + Mongo stack and recently we had an issue in prod where code was deployed with a @Indexed annotation. When deployed this will create an index on startup and can lock up the DB. We had this issue years ago, but it slipped pass code review and we had a 10 minute downtime because of this. Can this be prevented using custom rules in Datree?

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#49
post #46

Earlier quoted context omitted.

But it’s already in the git objects and therefore accessible to anyone who clones the repository? I am not 100% sure about that. Can someone confirm?

We educate our customers on how to delete the branch and remove it from history: https://docs.datree.io/docs/do-not-include-secret-files

I think you're miseducating your customers.

If creds leak, rotate those creds. Then, you check your logs to make sure there was no intrusion.

"Rotate the creds" gives the absolute best guarantee that they're useless. Three words I can explain to a nervous manager.

"What if someone got ahold of those creds?"

"Well, boss, here's the window in which it could have happened, and let's go over these logs together to see if it did."

Scrubbing the repo? I'm skeptical that you're getting rid of anything without push --force, and you sure as heck aren't running `git gc --prune` on the remote system, let alone `bfg`.

Re: Launch HN: Datree (YC W20) – Best practices and security policies on each commit

#50
post #49
post #46

Earlier quoted context omitted.

We educate our customers on how to delete the branch and remove it from history: https://docs.datree.io/docs/do-not-include-secret-files

I think you're miseducating your customers. If creds leak, rotate those creds. Then, you check your logs to make sure there was no intrusion. "Rotate the creds" gives the absolute best guarantee that they're useless. Three words I can explain to a nervous manager. "What if someone got ahold of those creds?" "Well, boss, here's the window in which it could have happened, and let's go over these logs together to see if…

I totally agree! you should rotate the keys! we explain how to get rid of it in terms of Git. This is in addition to rotating it. Sorry for not being clear
Post reply on HN