mh0pe
LoanDepot Lending Systems Down
Those automated tools are better than ever. Manual code reviews are very important, but automated tools at this point can stand in for "over the fence" pre-production code reviews, as long as periodic reviews occur. In particularly sensitive contexts, especially finance, code is always signed off on by security before release when it can have impact on anything important. It's all about risk management.
Additionally, the cloud and SaaS is nothing like it was a decade ago. Security is now more focused on compliance due to the nature of building software today. You used to maybe provision a handful of nodes on EC2, use an autoscaling group if you were super fancy, and probably integrate into a handful of third party APIs. Every business is different, but that was the core of running a workload. Now, I can delegate specific responsibilities to third parties and reduce both people and operating costs. But with that comes massive risk since you just transferred an internal business function to a third party you have no control over. The most common approach to that risk is through process: vendor reviews, compliance and cloud posture security management.
And then there's DevOps who ends up being ad-hoc security way too often with no relevant background (or interest).
All that to say, good, compassionate security teams do exist.
[1]: https://www.hashicorp.com/blog/announcing-hashicorp-sentinel...
[1]: https://docs.hashicorp.com/sentinel/downloads [2]: https://docs.hashicorp.com/sentinel/intro/getting-started/ru... [3]: https://github.com/hashicorp/terraform-foundational-policies... [4]: https://github.com/hashicorp/terraform-guides/tree/master/go... [5]: https://github.com/hashicorp/terraform-guides/tree/master/go... [6]: https://github.com/hashicorp/terraform-guides/tree/master/go... [7]: https://github.com/hashicorp/sentinel-sdk [8]: https://docs.hashicorp.com/sentinel/commands/apply
YAML ends up being a powerfully declarative model [2] for the state of a data structure, rather than a straight representation, ironically often enough being used in turn for an imperative model like in Ansible [3]. Definitely friendlier than JSON. But personally, I really like YAML because it lets me compose using a traits/mixins-like model using & and *, which allows for verbose, structured configuration inputs but concise configuration files.
docker-compose YAML files extension fields [4], imo, are a great example of this type of model in action. When you leave this much pre-deserialization flexibility in your configuration representation, it makes building cool stuff like docker-compose ECS support x-aws-* extension keys [5] and other plugin system-type capabilities much more straightforward than, for example, adding a new language feature to HCL.
[1]: https://github.com/google/skylark
[2]: https://en.wikipedia.org/wiki/YAML#Advanced_components
[3]: https://docs.ansible.com/ansible/latest/user_guide/playbooks...
[4]: https://docs.docker.com/compose/compose-file/compose-file-v3...
[5]: https://docs.docker.com/cloud/ecs-integration/#rolling-updat...
I have a solid and clear recollection of the good, which is useful from a business management and engineering career perspective. Literature retains on the first pass, which is very useful in operations for manual/business requirements/security framework ingestion, and I don't need to keep a TODO list or agenda (but still do for transparency's sake to my reports and superiors). Having an excess of information readily available gives a lot of opportunity to drive impact, and has allowed me to move vertically in my career very quickly. There's a feedback loop of retaining information, which presents me as more qualified to offer support to my peers, which puts more people in my direction soliciting input and building a positive reputation. With that, I made leadership in my early twenties, and it feels like it took less effort than some others to get here, based on what I've heard from other people.
Unfortunately for me and I'm sure others, I've been through a lot, and all of that retains just as well. It's not an active decision to retain. I'm not going into much detail on those events, but I've encountered about a dozen substantially negative events in my life, and having the information for those who've needed it has been helpful when necessary. It's been empowering to revisit those moments from a different angle as I've worked through those challenges.
All in all, not to be too cliche, but it's both a gift and a curse, but one I'm grateful to have.
What's far more likely as a source of random bot traffic is that a click farm is using real devices (it can take a bit to get abuse banhammered), and I'm guessing you're in a major metro area where a few bots are more likely to sneak under the radar. Elo[1] is deprecated these days, but much of ranking leans on 2nd- and 3rd-degree evaluation of both yourself and the other person, implying those users are generally evaluated as real and not reported much. Bouncer[2] helps the engine take this kind of data into account.
All this is to say if someone seems suspicious, leverage that Safety Toolkit. But Tinder seeding in fake users themselves would be quite visible externally after a quarter, cause a big spike in reports over time, damage user retention, daily sessions, and stickiness massively, all of which negatively impact ARPPU and paid conversion rates. Throwing tons of standard KPIs isn't worth a fractional boost in sales with the kind of revenue and growth factors[3] they're driving.
[1] https://www.theverge.com/2019/3/15/18267772/tinder-elo-score...
[2] https://techcrunch.com/2015/02/03/tinder-tests-limited-right...