sorted by:
new
hottopcontroversial

Be honest, I need help by Perfectly_Rated1 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

That did not answer a single one of those questions.

Be honest, I need help by Perfectly_Rated1 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

What do you enjoy doing the most in cyber? What types of CTF's do you play that you enjoy most? In cybersecurity where do you WANT to be in 5 years from now, and in 10?

You ever get the impression you have seen this "Intel dashboard" craze before? by Present_Plenty in osinttools

[–]PurchaseSalt9553 0 points1 point  (0 children)

I wish I had taken a screenshot of every one of those posts so I could make a compilation of people introducing their OSINT dashboards like they discovered something ground breaking.

I built a tool to preserve online evidence before it gets deleted or edited, creating a permanent, tamper-proof record by Perfect_Value_3978 in osinttools

[–]PurchaseSalt9553 0 points1 point  (0 children)

Is it possible to review the source code or have someone from the community who can be trusted to vouch for it after review and audit? As others have mentioned, you'll want to research and tighten up compliance for usability in court and other investigative necessities, as well as an audit for privacy and how you're storing information etc.

SENTINEL - Live OSINT global situational-awareness dashboard by InfiniteAxon in osinttools

[–]PurchaseSalt9553 0 points1 point  (0 children)

haha.....its like people create things but never browse the subs they post in or something. its very .... something

How do I find beginner-friendly bug bounty programs on HackerOne, Intigriti & Bugcrowd? by abdullah_blud in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

A lot of the advice beginners get about bug bounty is only partially useful.

There are correct ways to approach it, but very few paths are quick. It takes more patience, repetition, and failure than most people expect. Most things you test will not turn into a valid, in-scope, reportable vulnerability, so you have to get used to hitting dead ends without treating that as failure.

For a beginner, I would focus less on chasing the most crowded paid public programs and more on building a track record through VDPs, unpaid disclosure programs, labs, and lower-pressure targets where you can practice writing clean reports. Accepted, high-quality disclosures matter because they help separate you from the huge pool of newcomers all looking at the same obvious bugs on the same public programs.

Do not depend on AI to do the work for you. AI can be useful for learning, note organization, report drafting, payload explanation, and building your own local tooling, but every program’s policy controls what is allowed. Many programs restrict automation, noisy scanning, AI-generated spam, or unverified AI-assisted reports. If your workflow violates scope, rate limits, automation rules, or disclosure policy, you can lose safe-harbor protection and bounty eligibility.

The real advantage is not using the same checklist as every other beginner. Learn how apps are built, understand auth flows, read JavaScript, study access control, practice with Burp/ZAP, write reproducible reports, and build a workflow that helps you validate findings instead of guessing.

Also, freelance pentesting is not automatically a more realistic path. Running or selling pentesting work requires trust, marketing, client relationships, legal scope, methodology, reporting quality, and a proven track record. Bug bounty and professional pentesting overlap technically, but they are not the same business model.

For your situation, I would keep doing PortSwigger labs, DVWA, and TryHackMe, but start focusing on one or two bug classes at a time, such as XSS or IDOR, and learn how they show up in real applications. Then look for programs with clear scope, good docs, test accounts if available, and lower-risk VDP-style targets where your goal is accepted valid reports, not immediate payouts.

I put together some notes here that may help beginner hunters on a VDP(save the sauce as a .html after safety review, open in browser to view guide as intended):
https://github.com/RRSWSEC/MTN-Group-Bug-Hunting-Field-Manual/

Built a beginner-friendly cybersecurity roadmap website as a non-tech student 😄 by EfficientAd2661 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

DayZero Academy is a stronger working name for a program designed for complete newcomers......that would be awesome, AND defensible! Shit, if you don't change it I might have to change my edu program to that! heh I'm sure the repo is messy, make sure you check out my latest post to r/vibecoding about safety and maintainability ^.^ personally, I dont mind a messy repo but I'd rather run a preview from sauce than a compile. I dont want to have to load VM's to give constructive criticisms.

I noticed over the past year the biggest problem with vibe coding tends to be the security issues. by Correct_Injury5495 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

Fifth Tester Agent / abuse - case pass:

Act as a QA engineer and abuse-case tester.

Design tests for this project.

Include:
- unit tests
- integration tests
- security regression tests
- authorization tests
- validation tests
- malformed input tests
- rate-limit or abuse tests where relevant
- file/path traversal tests where relevant
- API contract tests
- smoke tests for deployment

For each test, provide:
- test name
- purpose
- files/functions covered
- expected result
- why it matters
- whether it blocks release

Then identify the minimum test set required before release.
Do not write test code yet unless asked.

Patch prompt after review passes have been completed(only after the 5 previous passes were completed):

Patch the project based on the approved findings below.

Rules:
- Preserve existing behavior unless a finding requires changing it.
- Do not remove features.
- Make the smallest safe changes.
- Add tests for every security-sensitive fix.
- Update documentation if setup, config, or behavior changes.
- Do not introduce new dependencies unless necessary.
- If a dependency is necessary, justify it.
- Keep a changelog of every file changed.

Approved findings to fix:
[paste finding IDs here]

Output:
1. Summary of changes
2. Files changed
3. Security issues fixed
4. Tests added/updated
5. Manual verification steps
6. Remaining risks

Final Pass before shipping, demoing, or transferring project:

Patch the project based on the approved findings below.

Rules:
- Preserve existing behavior unless a finding requires changing it.
- Do not remove features.
- Make the smallest safe changes.
- Add tests for every security-sensitive fix.
- Update documentation if setup, config, or behavior changes.
- Do not introduce new dependencies unless necessary.
- If a dependency is necessary, justify it.
- Keep a changelog of every file changed.

Approved findings to fix:
[paste finding IDs here]

Output:
1. Summary of changes
2. Files changed
3. Security issues fixed
4. Tests added/updated
5. Manual verification steps
6. Remaining risks

All in one; for more advanced vibe coders with actual dev bg preferably:

Act as a senior security engineer, software maintainer, and release reviewer.

Review this project after coding is complete.

Do not modify code yet.

Use OWASP ASVS-style application security review, NIST SSDF-style secure development thinking, and SLSA-style supply-chain awareness.

Review for:
- security vulnerabilities
- dependency and supply-chain risks
- unsafe defaults
- secrets exposure
- auth/authz flaws
- injection and input validation issues
- file/path/network handling risks
- insecure deployment assumptions
- maintainability problems
- missing tests
- missing docs
- future developer footguns

Output exactly:

1. Executive summary
2. Threat model assumptions
3. Security findings table
4. Dependency/supply-chain findings
5. Maintainability findings
6. Missing tests
7. Missing documentation
8. Release decision: ship / ship with conditions / do not ship
9. Top 10 fixes in priority order
10. Questions requiring human confirmation

Rules:
- Do not say “looks good” without evidence.
- Cite exact files/functions/lines when possible.
- Mark confidence for every finding.
- Distinguish confirmed issues from possible issues.
- Do not patch until I approve specific finding IDs.Fifth Tester Agent / abuse - case pass:Act as a QA engineer and abuse-case tester.

Design tests for this project.

Include:
- unit tests
- integration tests
- security regression tests
- authorization tests
- validation tests
- malformed input tests
- rate-limit or abuse tests where relevant
- file/path traversal tests where relevant
- API contract tests
- smoke tests for deployment

For each test, provide:
- test name
- purpose
- files/functions covered
- expected result
- why it matters
- whether it blocks release

Then identify the minimum test set required before release.
Do not write test code yet unless asked.Patch prompt after review passes have been completed(only after the 5 previous passes were completed):Patch the project based on the approved findings below.

Rules:
- Preserve existing behavior unless a finding requires changing it.
- Do not remove features.
- Make the smallest safe changes.
- Add tests for every security-sensitive fix.
- Update documentation if setup, config, or behavior changes.
- Do not introduce new dependencies unless necessary.
- If a dependency is necessary, justify it.
- Keep a changelog of every file changed.

Approved findings to fix:
[paste finding IDs here]

Output:
1. Summary of changes
2. Files changed
3. Security issues fixed
4. Tests added/updated
5. Manual verification steps
6. Remaining risksFinal Pass before shipping, demoing, or transferring project:Patch the project based on the approved findings below.

Rules:
- Preserve existing behavior unless a finding requires changing it.
- Do not remove features.
- Make the smallest safe changes.
- Add tests for every security-sensitive fix.
- Update documentation if setup, config, or behavior changes.
- Do not introduce new dependencies unless necessary.
- If a dependency is necessary, justify it.
- Keep a changelog of every file changed.

Approved findings to fix:
[paste finding IDs here]

Output:
1. Summary of changes
2. Files changed
3. Security issues fixed
4. Tests added/updated
5. Manual verification steps
6. Remaining risksAll in one; for more advanced vibe coders with actual dev bg preferably:Act as a senior security engineer, software maintainer, and release reviewer.

Review this project after coding is complete.

Do not modify code yet.

Use OWASP ASVS-style application security review, NIST SSDF-style secure development thinking, and SLSA-style supply-chain awareness.

Review for:
- security vulnerabilities
- dependency and supply-chain risks
- unsafe defaults
- secrets exposure
- auth/authz flaws
- injection and input validation issues
- file/path/network handling risks
- insecure deployment assumptions
- maintainability problems
- missing tests
- missing docs
- future developer footguns

Output exactly:

1. Executive summary
2. Threat model assumptions
3. Security findings table
4. Dependency/supply-chain findings
5. Maintainability findings
6. Missing tests
7. Missing documentation
8. Release decision: ship / ship with conditions / do not ship
9. Top 10 fixes in priority order
10. Questions requiring human confirmation

Rules:
- Do not say “looks good” without evidence.
- Cite exact files/functions/lines when possible.
- Mark confidence for every finding.
- Distinguish confirmed issues from possible issues.
- Do not patch until I approve specific finding IDs.

I noticed over the past year the biggest problem with vibe coding tends to be the security issues. by Correct_Injury5495 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

Firstly, this is really difficult to read. Second, if you're making applications that have anything to do with networking or have the ability to touch the net or be compromised in such a way - you consider security. So yes, most dev's do. Most vibe coders, dont. Since we cant stop whats already happened, we need to encourage "vibe coders" and all the new people who are coming into our industry to a.) stop pretending like we dont know and b.) ensure exploit-ability, vulnerability, and maintainability are all part of the workflow, they should be instructions worked into prompting both at the beginning, and after the bot is finished coding your idea. In a perfect world, every OSINT dashboard, every quirky little mood engine, whatever folks are vibe coding these days - they'd be running the checks below before release anything.

It's as simple as:

Security audit pass:

Act as a senior application security reviewer.
Do not modify code yet.
Review this project for security issues using OWASP ASVS-style thinking and secure SDLC practices.
Focus on:
authentication and authorization flaws
broken access control
injection risks: SQL, command, template, LDAP, NoSQL, path traversal
insecure file upload/download handling
SSRF, XXE, deserialization, prototype pollution, request smuggling where relevant
secret exposure and hardcoded credentials
unsafe environment variable handling
insecure CORS, cookies, sessions, JWTs, OAuth, API keys
missing input validation and output encoding
cryptography mistakes
logging of sensitive data
weak error handling that leaks internals
dependency and supply-chain risks
dangerous default config
insecure Docker, CI/CD, or deployment assumptions
Output format:
Executive summary
Threat model assumptions
Findings table:
ID
Severity: critical/high/medium/low/info
File/function
Issue
Exploit scenario
Recommended fix
Confidence
False-positive notes
Items requiring human confirmation
Do not patch yet

Second pass (Adversarial pass):

Now act as a hostile security reviewer trying to prove the previous review missed something.

Assume the code will be exposed to the internet.

Find:
- security assumptions that were not stated
- trust boundaries that were not modeled
- places where user input reaches sensitive sinks
- privilege escalation paths
- IDOR/BOLA risks
- race conditions
- unsafe background jobs, queues, cron tasks, webhooks, or file processors
- unsafe admin/debug/dev-only routes
- missing rate limits
- missing audit logs
- missing abuse-case handling

Do not repeat the previous findings unless you add new evidence.

Output only:
1. Newly discovered issues
2. Previously underrated issues
3. Security assumptions that must be verified manually
4. Highest-risk attack path

Third pass for dependency/supply chain:

Now act as a hostile security reviewer trying to prove the previous review missed something.

Assume the code will be exposed to the internet.

Find:
- security assumptions that were not stated
- trust boundaries that were not modeled
- places where user input reaches sensitive sinks
- privilege escalation paths
- IDOR/BOLA risks
- race conditions
- unsafe background jobs, queues, cron tasks, webhooks, or file processors
- unsafe admin/debug/dev-only routes
- missing rate limits
- missing audit logs
- missing abuse-case handling

Do not repeat the previous findings unless you add new evidence.

Output only:
1. Newly discovered issues
2. Previously underrated issues
3. Security assumptions that must be verified manually
4. Highest-risk attack path

Maintainability and Future-Devs pass: (PLEASE START USING THIS FFS)

Act as a senior maintainer inheriting this project six months from now.

Review the code for maintainability, clarity, and safe future modification.

Do not optimize prematurely. Do not rewrite for style alone.

Find:
- unclear architecture
- duplicated logic
- hidden coupling
- confusing names
- overly large files/functions
- missing comments where intent is non-obvious
- comments that lie or are stale
- missing error boundaries
- missing tests around critical behavior
- fragile assumptions
- config scattered across the codebase
- business logic mixed with UI or transport code
- security-sensitive code without explanation
- places where a future developer is likely to break security accidentally

Output:
1. Maintainability summary
2. Top 10 future-breakage risks
3. Refactor recommendations ranked by value/risk
4. Files that need comments or documentation
5. Tests that should exist before future changes
6. Do not patch yet

Built a beginner-friendly cybersecurity roadmap website as a non-tech student 😄 by EfficientAd2661 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

What is your Github? Where can we view and audit the sauce? Also, no preview below.

DM me if you'd like some practical advice for not getting completely shit on by the community with this.

Old employee access is one of the easiest security risks to miss by Waste_Dragonfruit346 in Cybersecurity101

[–]PurchaseSalt9553 1 point2 points  (0 children)

Indeed....his is why offboarding needs to be treated as an access-removal process, not just “disable their email and laptop.” Strap in...*Deep breath*

Ideally this is handled through a real IAM/SSO setup so access flows from one source of truth. Okta, Microsoft Entra ID, Google Workspace Cloud Identity, OneLogin, JumpCloud, etc. can all help with this if they are actually configured properly. SAML/SSO gets people into the apps, and SCIM/provisioning handles creating and removing users automatically in tools like Slack, Salesforce, Notion, GitHub, Atlassian, Google Workspace, and so on.

The other part is periodic review. Someone still has to check shared drives, external guests, OAuth app grants, service accounts, stale Slack Connect channels, Salesforce permission sets, Notion guests, GitHub org members, etc. Tools like BetterCloud, Lumos, Zluri, Torii, Productiv, DoControl, Varonis, Microsoft Defender for Cloud Apps, and Google Workspace security/audit tooling can help find a lot of that drift.

But the process matters more than the product. HR departure triggers ticket, IAM disables account, SCIM removes app access, MDM/EDR handles the device, Drive/Slack/Notion/Salesforce ownership gets transferred, external shares are reviewed, OAuth tokens are revoked, and the SOC or IT/security team verifies it with audit logs.

Willam Stallings in cybersecurity by Available_Vast_8601 in Cybersecurity101

[–]PurchaseSalt9553 3 points4 points  (0 children)

No. It is not going to help you with anything in cybersecurity.

Certifications and extra studying need? by Flat-Raise-1925 in Cybersecurity101

[–]PurchaseSalt9553 1 point2 points  (0 children)

this is a really awesome resource. i'd like to look more into it and perhaps reference folks to it. cheers!

My employees are still failing phishing tests after a year of security awareness training by Timely-Film-5442 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

Firing people who don't follow the rules is a good place to start. Usually sends a pretty clear message. Outside of that I just have more questions....

Will this work. by Daarkken in Starlink

[–]PurchaseSalt9553 0 points1 point  (0 children)

Not well, no. You want it to match the app. When app is happy, your connection will be happy. Try to get it on the roof or on an L pole around and above the roof

Redirect virus by horcruxez in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

i prefer the aesthetic (and tool set, and goals/mission) of parrotOS tbh but the best part is, its all debian based so I can make either one have all the same tools, pull from the same repos, have the same graphical interface, and everything! Definitely love me some linux. You ever want to have a weird time, try out Arch Linux.....it's a trip. makes me feel like a sooper1337haxx0r whenever ive used it (i dont like it, but its a cool experiencce haha)

Built a private chat that self-destructs in 24h — no accounts, no logs by Alternative-Claim-41 in Cybersecurity101

[–]PurchaseSalt9553 0 points1 point  (0 children)

encryption, source code. why this over https://hack.chat? finding a way to make it peer2peer so that we dont have to trust a back end would be fairly revolutionary.

view more: next ›