How do you take care of security in your startup? With a low budget and limited resources, what are the best companies to perform security testing and hardening?

Öncelikle bu konunun bir reklam olmadığını, sadece liseli gençler olarak düzenlediğimiz bu etkinliğin daha fazla kişiye duyurulması amacıyla paylaşıldığını belirtmek isterim.

Kısaca: Biz 4 kişi HASBL CTF adında Jeopardy formatında olacak bir CTF düzenliyoruz, katılım linki en aşağıda mevcuttur.

Peki CTF nedir? CTF yani; Capture The Flag (Bayrağı Yakala), siber güvenlik alanında farklı kategorilerdeki becerilerimizi test etmek ve geliştirmek amacı güden bir yarışma formatıdır. Amacımız kategoriye göre verilen sorudaki açığı bularak cevaba (flag'e) erişmektir:

Kendimizden bahsetmem gerekirse biz sosyal bilimler lisesinde 11. sınıf öğrencisi olan 4 kişiyiz ve birçok CTF'e katıldıktan sonra; "Neden soru yazmayı da denemiyoruz?" dedik ve kendi CTF yarışmamızı yapmak istedik. Elimizden gelenin en iyisini yaparak bir şeyler yaptık işte...

Etkinlik detaylarına geçmek gerekirse:

Kategoriler:​

• Web: Açtığınız Instance'da zafiyet bulup flag'e ulaşmak.
• OSINT (Açık Kaynaklı Bilgi/İstihbarat): Soruda verilen foto/video, sosyal medya hesap adı vb. ortamlarda kanıt inceleme ve analiz ederek flag'e ulaşmak.
• Cryptography (Kriptografi): Şifre kırma diyebiliriz basitçe. Kod ve/veya verinin mantığını çözerek şifrelenmiş flag'i okunabilir hale getirerek flag'e ulaşmak.
• Reverse/Reverse Engineering (Tersine Mühendislik): Derlenmiş bir yazılımı yada makine kodunun bazı programları kullanarak nasıl çalıştığını çözüp okunabilir hale getirme ve flag'e ulaşmak.
• Pwn (Zaafiyet/Sömürü): Hedef olarak verilen sistemin güvenlik açıklarını bularak sisteme sızıp yetki yükseltme ve flag'e ulaşmak.
• Forensic (Adli Bilişim): Dijital kanıtların (log, disk görüntüsü, wireshark vb.) inceleyerek flag'e ulaşmak.

Kategorilerin tanımını yaparken ben bile kötü bir şey yapıyormuş hissiyatına kapıldım ama emin olun öyle bir şey yapmıyoruz kesinlikle 

Tarih:​

• 29 - 30 - 31 Mayıs tarihlerinde 48 saat sürecek.

Platform:​

• CTFd altyapısı üzerinden kendi sunucularımızda (Google Cloud) gerçekleşecek.
• CTF Time üzerinden de yarışma duyurusu yaptık ama kabul bekliyoruz, CTF'lerde önemli olduğu için kabul aldığında eklerim buraya.

Kurallar: Kurallar sitemizde yer almakta ama kısaca önemli birkaç kurala değineyim.​

• Takımlar en az 1, en fazla 4 kişilik olabilir.
• Flag paylaşımı yapmak yasak.
• Yarışma boyunca write-up yayınlamak yasak.
• Yarışma sürecinde yarışmacıların birbirine saygılı olması ve sportmen olması önem arz etmekte.

Kayıt ve Daha fazla bilgi için:​

• Kayıt ve daha fazla bilgi için sitemizi bağlantı kımından ziyaret edebilirsiniz.
• Yarışma sürecince kayıtlar açık olacak ve belirli bir şart olmaksızın isteyen herkes katılabilecek.
• Ödüller daha belli değil (TBA) maalesef..
• Lise düzeyinde kısıtlı süre ve bütçede hazırladığımız bu etkinlikte hata olacaktır ama bunları düzeltmeye ve kendimizi geliştirmeye özen gösteriyoruz.
• Sitede ve yarışma genelinde bir öneriniz, sorunuz olursa; bunları duymakta, cevaplamakta ve geliştirmekten memnuniyet duyarız.

Şimdiden ilgi gösteren herkese ve CuteTopia Sub'ına bu konuyu açamama izin verdiği için teşekkür ederim.

Hi everyone,

I submitted a report to a public Bugcrowd program (Lightspeed Retail / Ecwid scope) regarding an active historical API token exposure that allowed authenticated administrative API access.

How it was discovered:
While performing normal recon using waybackurls against in-scope assets, I discovered a historical endpoint response containing an API token.

What happened next:

• The token was still valid against the target’s live in-scope API.
• It allowed authenticated administrative API requests.
• I provided proof of successful live access.

The report was marked Not Applicable with the explanation that third-party indexed exposures (e.g. VirusTotal, Wayback Machine, Telegram, etc.) are considered external causes and not security risks originating from the program.

My confusion is that my intended impact was not the historical indexing itself, but rather:

• The credential remained active after historical exposure
• It granted live privileged administrative access
• It appears no revocation / rotation occurred

So my question for triagers / experienced hunters:

Would this still normally be considered out-of-scope simply because discovery originated from historical indexing?

Or could this reasonably be argued as a credential lifecycle / secret revocation failure instead of just “third-party exposure”?

If disputing this decision, what technical evidence would best support reconsideration?

Would you:

• Politely request reconsideration with stronger framing?
• Re-submit under a different vulnerability class?
• Accept closure and move on?

Any triager-side perspective would be appreciated.

more than 90% of devs now use AI coding tools and something like 40% of committed code is AI-generated (or even more) Our security review process was already a bottleneck, now it's completely underwater. Are your teams adapting? How? New tooling? New processes? Or just accepting the risk?

I've been in IT for 24 years. The last 8 years have been pretty much all Azure cloud engineering. I'm thinking of pivoting into infosec since I have a couple of current CISSP holders who can vouch for me and the security related projects I've worked on in those last 8 years. I also recently got my MS Certified Azure Cybersecurity Architect cert and have an older Security+ that's still active.

I'm studying for the exam but I'm curious for how others have made this kind of career change. My hope is to be hands-on-keyboard in Azure, not so much a "thought leader". I want to be the one who says "look, this has to happen for our compliance requirements, I'll help with the work, let's get it done" and actually work on the Azure parts. It's what I do well, but since it's getting tougher to find Azure cloud engineering roles, this seems like a natural move.

Has anyone else done this? What was your pivot like? I'm guessing I'll have some serious resume re-architecting to do in order to highlight what I did for infosec projects as opposed to business as usual, but what else should I be prepared to do? Is it realistic to go from senior cloud engineer to senior cloud security engineer or am I facing pay cuts to start from junior level?

Started with a few exceptions for employees in regions where SMS delivery is unreliable. brazil, egypt, a couple others. temporary, supposed to be reviewed monthly.

fourteen months later we have 34 active exceptions. some accounts with elevated permissions that should never have been on the list. a few for employees who already left. original justifications mostly gone.

the security gap isn't the SMS failures, it's that our response to them was informal and compounded quietly over time the accounts most likely to have degraded MFA are now in the regions we have least visibility into.

we're looking at authenticator apps but last rollout stalled in brazil during enrollment. hardware keys feel like overkill for a 500 person company. what are people actually using for regions where SMS just doesn't work and what did the exception cleanup look like when you switched.

 vendor handles the scanning part of our docker security stack. every week their own components show new CVEs in the scanner image.

we open tickets, they either get marked low priority or sit without response. last real reply was weeks ago.

compliance doesn’t care where it comes from. scan fails, audit flags it, and it lands on us.

we tried pushing contract clauses around secure delivery and patch timelines, but once it’s upstream OSS inside their image, everything slows down.

right now we’re logging formal risk acceptances with compensating controls just to stay audit compliant. documented, signed, reviewed.

starting to feel like the bigger issue is relying on vendor-bundled images we don’t control.

has anyone managed to get vendors to move on this, or did you reduce dependency on their images?

I have a friend who recommended this tool to me, been having a lot of problems with spam, now I don't know much about data brokers and whatnot but it seems to be working well for him, anyone tried it before or anything similar?

Everyone’s talking about AI replacing cybersecurity jobs.
But honestly, people who know how security actually works will always stay valuable.

The bigger issue is beginners getting lost between random certs, YouTube rabbit holes, and outdated roadmaps.

So I put together a structured roadmap with resources, tools, SIEM/SOC paths, cloud, malware, detection engineering, etc.
It’s the kind of thing I wish someone handed me earlier.

Dropping it in here for anyone who needs direction.

https://cybersec-roadmap-opal.vercel.app

Every "how to get into cybersecurity" guide follows the same script:

• Get Security+
• Do TryHackMe
• Build a home lab
• Apply for SOC/Pentesting jobs

It's not bad advice. But it completely skips Step 0:

Which Cybersecurity Career are you actually trying to build?

There are 12+ meaningfully different career paths, penetration tester, GRC analyst, threat intelligence, cloud security, incident response, digital forensics, malware analyst, security architect, etc.

Each requires totally different training.
Different certifications.
Different skills.
Different personality types, even.

But somehow, every beginner resource assumes you already know which one you want. Or worse, assumes you want to be a pentester.

I've been researching this gap for months, and I'm genuinely curious - how did YOU figure out which path was right for you?

Was it random?

Did someone guide you?

Did you just fall into it?

Recently reported an auth-related vulnerability to an Indian e-commerce company while casually browsing their site. The issue was pretty straightforward; ability to trigger account lockouts without auth that can be abused at scale during sales/events affecting each and every user of that site.

To their credit, the team acknowledged the report & fixed it and even sent over a small ₹2k voucher despite not having any public vdp. So this isn’t meant as a rant against them specifically.

But the whole experience genuinely got me thinking about how security research is still viewed by a lot of Indian companies. A lot of reports still get treated more like customer support tickets or they most of them dont even reply unless escalated with certin. And while I’m not expecting huge payouts from companies without formal programs, vulnerabilities affecting authentication and user access can absolutely have real business impact if abused.

Even rewards like this feels bad for a vulnerability of that scale. I honestly feel we’re just a few major breaches away from mass vdp & bug bounty adoption in India.

Curious if others here have had similar experiences

I’m currently learning bug bounty / web security, and I want to start moving into cloud bug bounty / cloud pentesting (AWS, Azure, GCP).

Before jumping into cloud-specific labs and exploitation, I want to build the right foundations first.

What are the core fundamentals / prerequisites I should study and understand well before taking cloud bug bounty seriously?

If anyone here has followed a similar path, I’d really appreciate it if you could share a roadmap or recommend good learning resources to get started.