HN user

alp1n3_eth

156 karma
Posts8
Comments66
View on HN

What are you using on the backend to actually scan it? Is it just ZAP / Burp Scanner? Or are you scanning the code itself, and just using a Semgrep / Snyk approach?

The landing page being free-tier Framer is a little sketch, the main contact should also probably be a form or an email address instead of a non-US phone number.

Is AI used throughout the entire process or just mainly focused on providing remedation recommendations based on the output of other tooling (scanners, JS analysis, secret scanning, etc.)?

Interesting project! Looking forward to see how it works and evolves.

A lot of people don't self-host it, even though it is open core. This is due to their docs being garbage and tons of differences between the offerings, so you can't even rely on the main docs if you're self-hosting.

It's easier to just become familiar with a DB UI tool like Beekeeper or DataGrip and spin up your own things. I'm also not a huge fan of being "locked-in" to so many things (including their auth). I think most projects would be better off keeping these parts separated, even if they are using third-party services to handle them, as it would be way less overhead to migrate out.

Yep! I was sad to see Skiff shutting down, as I loved their UI and there isn't a lot of tough competition that can match ProtonMail.

I had already left Notion as the app kept getting slower / bogged down and they added tons of useless clutter, and refused to support any form of E2E/local encryption.

I'd say it doesn't exactly meet the minimum standard for a CVE, as it's more of a technique vs. an actual vulnerability in an application/library. If there was a repo that had a vulnerable component that was currently infected through the manner described, that specific instance would probably qualify as a CVE.

Since this is a technique / overarching issue, it leans more towards being a CWE. Maybe something like:

- CWE-506: Embedded Malicious Code or - CWE-829: Inclusion of Functionality from Untrusted Control Sphere or - CWE-1395: Dependency on Vulnerable Third-Party Component

From Snyk's docs they also explain it: https://github.com/snyk/user-docs/blob/main/docs/manage-risk...

"In almost all cases, malicious packages are not assigned a CVE ID."

You're a frontend web developer, so I'm assuming you're going to want to work in the areas of either:

1) application security engineering 2) application penetration testing 3) devsecops 4) vulnerability management

It really is a big difference from each person on how they "break into" it. You've got great foundational qualifications, and probably just need to layer on extra "security" ones, if you don't already have them. If you're looking to start a company / start freelancing -- I've got no clue about that though.

If you're just dipping your toes further into the web app security side, OWASP has great labs, resources, etc. They have the WSTG (more for pentesters) and ASVS (more for devs), and of course their cheat sheets as well.

PortSwigger has great resources to read through on vulnerabilities and labs that will cover a ton of different vulnerabilities. HackTheBox also offers certification pathways: CBBH and CWEE, CBBH is more beginner/intermediate and involves a blackbox approach, where CWEE is more whitebox (from what it looks like).

Just because systems have gaps, doesn't mean the orgs actually want help with those gaps, esp. unsolicited. You could always take a look at bug bounty as well (through HackerOne or BugCrowd), but it can be pretty brutal for a beginner as it can involve a ton of recon or "going deep" to reach untouched areas of an app.

Externally / Blackbox options would be Nessus, Nuclei, OWASP ZAP (as you mentioned), and Burp Suite. The two latter only work well when used in combination with manual methods though, as they won't pick up business logic, auth bypass, MFLAC/IDOR, etc. on their own.

A lot of scanning templates / rulesets won't be 100% accurate or up-to-date, and will easily miss a lot of big things, so having it pentested by an actual person is always important.

From the source code side of things, Semgrep / CodeQL, Veracode / Snyk, Burp Enterprise (CI/CD), etc. are good options. But again, most places shouldn't get just scans, there should be a manual component involving a security professional who knows what they're doing.

XBOW is making some pretty cool strides in the meantime from a blackbox perspective though.

I appreciate Caido because of the ability to save projects in the free tier, which I use for (personal use) different projects and tinkering. Burp Pro is my daily driver at work, and I think Caido could certainly use some improvement to their UI/UX, as it's about as bad as Burp's (which isn't great).

The speed is an awesome gain though, as it's truly lightweight and runs a million times better than Burp. Even without Extensions, some days my Burp Pro is just randomly crashing and gobbling up CPU/RAM for no obvious reason and requires a program or system restart. I've never run into the same issue with Caido.

If you want a super bad audio-related journey, try fixing external speakers connected to a Linux box. It's abysmal, and 99% of it can only be done via the CLI. Nothing wrong with that... but for something so normal I expected more ease-of-use.

Weirdly enough... not always.

When it comes to random companies running their own VDP vs. hiring it out, it can be less than standard despite there being lots of resources on setting it up. I've seen ones that only include a phone number, the email address listed doesn't exist anymore, etc.

Others have had to even get to the point of contacting an executive via LinkedIn despite there being a VDP page / security.txt.

Surprisingly, Go is great for CLI tooling. It may not have the insane speed that carefully planned and written Rust does, but it's very easy to write and be performant without even needing to go to great lengths to optimize it.

I generally say that anything under 500ms is good for commands that aren't crunching data, and even Python CLI tools can come in under that number without too much effort.

Before needing an LLM for it, they might want to ensure their doc system is using a search system that actually works. There's too many doc-focused templates / apps that have the worst search possible.

This is one area where I'll actively discourage fragmentation of the existing ecosystem. Currently in the U.S. it's:

1) PawBoost 2) Facebook Groups (which PawBoost usually posts to as well) 3) NextDoor

Past that, the animal needs to be captured and checked for a chip. Having 10+ different apps to report lost animals essentially means there's zero point to posting to one in the first place, unless there is some distributed system they all would agree to operate on top of (maybe ATProto? idk).

I think there's a difference between Microsoft refusing to support completely operational hardware for their new OS, and Apple not adding extra features / support into a pre-existing product just because the underlying tech is now more powerful.

It sounds weird, but going OS #1 -> OS #2, you don't expect your hardware to impact it from a computer point of view. But going from iPad #1 -> iPad #2, why would it all of a sudden have a completely different OS and support when iPad #1 is even still receiving updates?

We've reached the age where you need 16GB ram to even keep some tabs open on Mac + Windows, and in terms of versatile computing and gaming I think cloud-based Linux really is the answer. Once it comes time for my next gaming computer upgrade, I'm pretty confident with just using a game streaming platform vs. paying $500 for a new graphics card + anything else (since my current MB doesn't support Windows 11...). Same goes for coding, just connect the IDE to your dedicated cloud box and away you go, all the power and scale you could ever need from $10/mo and up.

I don't know how it works overseas, but it sounds like this is a plus for US companies hiring US employees. According to the laws the company is required to fully ID you before hiring, which means either:

1) Hopping on a video call and placing the passport or (driver's license + birth cert) in front of the camera. 2) Going to an in-person business that the company is friendly with to have their HR verify you.

Both of these usually involve sending a photo of the documents in addition to the in-person/video verification.

#1 is very popular, and in a legal grey area ever since COVID. More standardized/strict businesses (banking, university) will require #2. Either one of those options kills this outright (ignoring the other billion red flags they should have seen pre-interview).

Along with a background check, which even the crappy ones will verify using things like W2s, I don't really see this as a concern, unless you've got sketchy hiring practices and hire in countries you aren't familiar with.

They could build an optional "risk score" that open-source community-oriented projects could turn on. It could include requirements like having something dependabot-esque along with CodeQL enabled. Rules could be created for CodeQL (if they haven't already) that check for obfuscated code, suspicious access (keychain, password storage, etc.) and other items.

On top of that it could have forced release binary scanning via VirusTotal/insert-malware-scanning-vendor-here.

War between the EU and US, however unlikely, probably wouldn't mean all your devices stop working right away. At absolute worst, patches would stop rolling out to EU-owned and operated devices, so you'd still have your hardware, the current version of your OS, your local files, etc.

Back up all of your iCloud(it can be exported). Keep a copy on hand, and keep a copy encrypted in the cloud using something like BackBlaze.

Even though Linux has strong ties to the US, some of the distros aren't wouldn't be completely restricted (I'd wager most of them), and aren't all fully US-based. Keep a copy of Asahi / whatever flavor can run on your Mac handy on a bootable USB stick.

You could grab a cheap android phone as a backup to your current iPhone and flash it with a fork, like Graphene.

The general data protection and backup strategies largely apply and work well for this scenario.

As @ianpurton stated: Defense-in-Depth works.

The instructor is teaching a class with some people who may be bad programmers, some that may be good, and some that may be great. The safest general advice is to rely on well audited and community trusted third party libraries.

Ofc those libraries were built by someone in the first place, but a lot of them have 50+ contributors and have in-depth controls and standard reviews. A more generalized answer is "it depends".

Regarding the point that many libraries have been exploited, that's true, but the counterpoint is if that well audited library with tons of reviews and contributors was exploited, what makes a single individual or small team think their code is completely secure?

For the above statements, these are mostly made for questions surrounding security-related libraries; authN, authZ, middleware/routing, etc. There's always a chance the random JS manipulation library might introduce an XSS vuln or something, but it pays to be safe, especially where it really counts.

For in-house vs. pulling a third-party, I'd look at: - How active contribution is - How much it's used - Who is using it - Does it solve the program's need exactly - Where it's hosted / If it's had any reviews

The last point can help give a little reassurance because if it's a library being tracked by a body/org you'll probably get an update if a CVE is found. Also, if the library is hosted somewhere like GitHub it should have the added benefit of CodeQL access.

Tooling for asciidoc (last time I used it) was super sparse and next to unusable. There was primarily one underlying engine everyone relied on to do cross-filetype generations, and the available editors was pretty bad as well. Of the few free ones, the recommended list was like:

- JetBrains Plugin - VSCode Plugin

I wanted to like it, but doing anything was a bit of a pain. If I need that level of structure, I'd rather work with something like Typst. Otherwise Markdown works fine.

There's probably going to be a flood of lawsuits, complaints, etc. following this. Cleaning up inefficient gov processes and waste would be good, but this is the completely wrong way to go about it. A single team, made up of extremely young people, some of which haven't even finished college yet, is not qualified in the slightest to do so. This is on top of them having no gov experience, and experience with how things work on the individual teams they're trying to clean out.

Not to mention they've probably already accessed Secret and up levels of classified data without a clearance, which would get any normal gov employee fired and potentially thrown in jail depending on the offense.

I also want to highlight that OPM is the backbone of workers rights for the government. Most skilled positions working directly for the gov are already underpaid. OPM was one of the few pros they had to offer; robust worker rights that are required across the fed.

Curl is nice but its syntax leaves a lot to be desired. It's also hard to distribute to others a "collection" of them, as you're going to end up with troubleshooting questions from less-technical users, especially when it comes to multi-request items that require pre/post response processing.

Idk if they have it yet, but last time I used the VS Code REST extension it still didn't support pre/post request scripting (which is already insanely fragmented syntactically across Postman/Insomnia/Bruno).

For any long-term things that would normally be in a Postman collection and distributed to others / outside teams, I usually end up with folder-separated Hurl scripts (similar to your use).

I can totally see how the REST extension is way easier for point & shoot from within VSCode though!

Obligatory "Substack has a Nazi Problem" article: https://archive.is/uyugO

Obsidian Publish, Micro.Blog, Ghost, BearBlog, HackMD, etc. are all great places to start, with less "baggage" associated with them. I know a lot of people write on Medium as well, but the account requirements that pop-up randomly are super annoying.

Garmin's smartwatch line and SOS communicators now have a massive target on their back. Now that the satellite availability issues are going to be solved, they just need to push battery life further for the watches and they'll be golden.

There will be no point other than simplicity / physical buttons to get a Garmin watch over an Apple watch if you have an iPhone pretty soon.

Garmin w/ eink screen, not great app, bad Apple compatibility = $300, latest AW series 10 = $380

My assumption is it's for reducing the number of things they need to configure, and therefore troubleshoot.

It's easy to say "The newest Kali release is the distro the org will use" instead of "Use whatever Linux flavor you want and here's an install script that may or may not work or break depending on your distro and/or distro's version".

Them spending time troubleshooting a setup that's out-of-spec is still time billed, so it's better for their customers for everything to roll smoothly too. They also just want to execute their job well, not spend time debugging script / build issues.