appsec

This magazine is from a federated server and may be incomplete. Browse more on the original instance.

N7x, in Stir Trek 2024: Call for Speakers

Why the downvotes? This is a call for speakers to a security conference

ChatGPTOnline, in ChatGPT Hallucinations Open Developers to Supply Chain Malware Attacks

the development of ChatGPT it gives bad guys the opportunity to be creative. what matters is the user’s way

dingleberry, in GitHub Copilot, Amazon Code Whisperer emit people's API keys

Dear God. That’s like the first thing you’d test internally. We really do be moving fast, breaking things.

ExtraMedicated, in GitHub Copilot, Amazon Code Whisperer emit people's API keys

You shouldn’t be hard-coding API keys, and definitely not committing them to the repository.

infinity11,
@infinity11@infosec.pub avatar

What should you be doing with API keys?

CameronDev,

I think, and i could be wrong, but you should be storing them in a password manager style service, and then have your application pull them out.

Which is just commiting the keys with extra steps I guess :/

ExtraMedicated,

I guess it depends on who should have access to them, but at the company I work for, we keep all the private config files backed up in a secure place (local network server, encrypted cloud storage, whatever) and the config files are added to .gitignore. This is especially important for databases with personal info.

pixxelkick,

We load all secrets in from an instance of Hashicorp Vault we have running.

It’s pretty easy API to use, has packages for most languages, has a solid docker image, and is compatible with pretty much every type of storage under the sun.

tmRgwnM9b87eJUPq,

For local development you would definitely keep them in a config file. Nothing wrong with that.

For production they are set during the release process.

Nothing is more expensive than developers needing to find all the configs and keys to just start up a project to make a small fix somewhere.

pixxelkick,

A config file outside of the repository to be specific.

On Linux it can go somewhere under ~

On windows it can go somewhere in AppData

Ie; ~/YourAppName/Secrets.json or whatever your config file flavor is. Json, yaml, xml, whatevs

tmRgwnM9b87eJUPq,

No. For development purposes I want my devs to be able to clone the repo and start.

So the development config files are inside the repositories.

DoomBot5,

Wow, that’s a terrible security process even for development configs. How about adding a script they can run right after cloning to pull the needed keys from a secure location using their own user credentials? Plenty of solutions out there.

tmRgwnM9b87eJUPq,

So let’s say the code base leaks.

Let’s say our VPN was also compromised.

Then what is the worst that can happen? Some internal dev api with no real data in it can be tested by hackers.

netr0m, in OWASP Top 10 for LLMs (v1.0)
@netr0m@infosec.pub avatar

Here’s a link to the full PDF.

And this is their short slides.

N7x,

Thank you!

mwguy, in Feedback open until 31 of August for CVSS 4.0

I get why they’re doing it. But the truth is that there are still places using CVSS 2.0 to grade their vulnerabilities. The switch to CVSS 4.0 is going to take forever unless there’s some conversion logic from 3->4.

N7x,

That’s kind of legacy debt at some point. I understand why they still want to move towards evolving the standard

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • appsec@infosec.pub
  • tacticalgear
  • DreamBathrooms
  • InstantRegret
  • magazineikmin
  • khanakhh
  • Youngstown
  • ngwrru68w68
  • slotface
  • everett
  • rosin
  • thenastyranch
  • kavyap
  • GTA5RPClips
  • cisconetworking
  • JUstTest
  • normalnudes
  • osvaldo12
  • ethstaker
  • mdbf
  • modclub
  • Durango
  • tester
  • provamag3
  • cubers
  • Leos
  • anitta
  • megavids
  • lostlight
  • All magazines
    •