d0ublespeak

Zepto | Senior Security Engineer (product security) | REMOTE (AUS) | https://zepto.bamboohr.com/careers/104

As a Senior Security Engineer (Product Security), you will play a significant role in keeping our product safe and secure by building on and maturing Zepto's product security practices. You will work hands-on and shoulder-to-shoulder with Engineering and Product teams, providing guidance and coaching across the software development life cycle while continuing to raise the bar on our security expectations and capability.

This is a security role at its core, but not a gatekeeping one. We are builders – we expect you to read and write production-level code, build tooling and automation, and contribute paved-road solutions that engineers actually want to use. Reporting to the Security Engineering Lead, you will work closely with them to develop and build Zepto's product security strategy and approach. You will apply a consultative and advisory approach when working with the wider Zepto team, empowering them to work confidently and to use the self-service capabilities you help establish.

We have excellent working relationships with our developers and we need to keep it that way. We are not the team of no. We are the team that helps make things better.

Zepto is moving quickly towards an AI-native way of building and operating. You will be someone who is already experimenting with AI and agentic tooling, or is genuinely keen to, and who is open to developing the skills to secure these systems as we adopt them. Within the Security team, you are the go-to person for:

Secure development practices Vulnerability management Security architecture advice

Working in a scale-up, means you get the opportunity to flex your skills in a variety of ways. We are agile and always willing to roll up our sleeves to get things done. You can, however, expect your day to day to be involved in the following:

Coach engineering teams and collaborate to ensure every step of the software development life cycle follows security best practices Design, build and maintain security tooling, automation and paved-road controls as production-quality software Conduct security assessments and architecture reviews of Zepto's applications and services Embed within project teams to ensure they are effectively considering information security risk and prioritising security controls Establish and document security architecture and practices in collaboration with the Security Engineering Lead, Product and Engineering teams Work with the Security Engineering Lead to support Zepto's adoption of AI and agentic systems, and experiment with AI tooling to improve how the Security team works Help manage application security incidents in collaboration with the rest of the Security team

Honestly, you could sub the other big Bug Bounty platform for H1 in this post and you’d be still extremely accurate.

Hashes or it didn’t happen.

Heaps, most recent is just a little applet that stops my Mac from going to sleep with the lid closed: https://transitivedev.gumroad.com/l/doppio-app

Bunch of security tools: Some are at https://diffsec.dev others:

https://github.com/diffsec/quokka

https://github.com/ihavespoons/hooksy

This is such a nothing burger corporate ad. They purchased a cheap cable and it sucks. So let’s X-ray it and make a thought piece post about implants…

It can be less/more than 2 percent too dependent on income. But yes we are extremely blessed in this country with a healthcare system that isn’t perfect but is extremely affordable.

With seeing a doctor we have two main systems that you can use and each will have a different waiting time. Bulk-billing and the fully public option has longer waiting times because there aren’t enough clinics/specialists or doctors, The reasons for this are complex but they stem from an unwillingness from prior governments to raise the amount the government pays for each service to adequately to support this system meaning less doctors and practices being willing to support it.

You’ve then got practices/specialists etc… that charge copays and they tend to have less waiting times because less people are willing to pay copays. A lot of these practices will also do outright private billing which is what you’re experiencing.

This isn’t an inherent flaw of public health care. A lot of the health care problems in this country (Australia) stem from a continued disinvestment in the public system after a decade (prior to the current government) of conservative mismanagement. Most state funding here comes from the federal governments standard sales tax. They intentionally gimped our public system to fund a private system that isn’t financially viable. Reversing that is going to take time. The problem exists it’s just important to attribute it to the correct sources. Medicare (our public insurer) is an incredible privilege that we should protect and hold our leaders accountable for managing.

I just don’t see why Joe Public will ever care about decentralisation as a concept.

We tend to hand wring about principles within the tech sphere, when the bulk of people just want a place that won’t make them feel immediately (longer term doesn’t matter) crappy when they use it, whatever that means for them. That tends towards centralisation because decentralised services have awful moderation and tend to create an even stronger strain of groupthink.

Is this new? I’m a bit confused. It’s just… GitOps… like how a lot of reasonably sized businesses do DevOps.

This article feels self defeating. It’s rewriting the meaning of the word bubble itself. There is a speculative asset bubble. Whilst I think there is some correctness in saying that drawing parallels with the Dotcom boom/bust is intellectually lazy I still think this acts as a notable precedent. Is there potential for AI usefulness long term? Yes, will it take exactly the same form as now or do the products and services exist now? No. So there is some utility in comparing the two. Either way this article reads like a bit of cope.

Shameless puff piece

Yeah CTFs are definitely a big part of our culture in security. We’re blessed with unending material in the form of vulnerabilities and mis configurations :)

I will say (as someone that runs, organises and builds CTFs) organising meaningful CTFs is becoming slightly challenging though, a lot of challenges are highly treaded ground where one very mature team just comes along and clears the table.

That and generative AI can solve a lot of CTF problems with enough prodding if it’s at all derivative.

I put together a little tool for people (it’s me, I’m people) that helps identify GitHub actions in use across the organisation.

It’s currently early days and I’m planning to expand it, but at the moment it: - runs across either a single repository or an entire GitHub Org - provides a list of actions in use per repo as well as a list of most commonly used ones (currently this list isn’t perfect I am working on improving this) - can be run as a GitHub Action that enforces a deny or allow list of actions

Coming up: - integration with GitHub Security Scanning API - GitHub App - static analysis for actions quality and safety - analysis of action pinning and enforcement (similar to ratchet) - a potential blacklist of malicious versions - maybe some cool stuff around immmutable actions.

Famous chemists, physicists and computer scientists. Turing, Bernoulli, Lovelace etc… with a rough association between the namesake and function.

Prior to that was using Jupiter and its moons but ran out of named ones.

I think this is really cool and a smart way to approach this problem. That being said, the physical isolation of the YubiKey is what makes it useful. Having to physically press a button is the real isolating factor, the interaction is physical and not determined by a piece of software.

Imagine AWS wanting to get rid of attribution. Sounds like something that isn’t the slightest bit disingenuous.

The Uninhabitable Earth by David Wallace-Wells - super eye opening.