As a dev, you should start learn about the most common bug classes and get a proper understanding on what is happening and how you can prevent them. Then it's worth looking into how you can exploit them. If you work for a big company, you may be able to spend some time working along your security team, that will help you get a foot in the door. Security teams are always looking for people who already understand the code bases and deployment processes and want to inject security everywhere :)
<shameless_plug>You may like https://pentesterlab.com/ if you are looking for a course</shameless_plug>
Fair point and you're (obviously) spot-on for the attacks and very valid point on the names used.
It's a problem with most learning resources, you get what you put it. Most people get out of these exercises one of these two things (or both):
#1 a real understanding of the issue (best case scenario)
#2 awareness that encrypted/signed doesn't mean bulletproof.
Worst case scenario, I think these exercises help people with #2 and may get them to look a bit deeper when they are reviewing applications. It's not meant to be a crypto training (IANAC), the goal is to help people gain some awareness around crypto issues they may encounter during an assessment.
Got in during the beta. Incorporated in less than 2 weeks. The process was quick and straightforward. I started the paperwork to get a debit card from SVB 3 weeks ago and I should receive it in few days.
Could you share a little more details about the debit card process? How was the paperwork, how do they ship the card (courier company or regular international mail), do they ship anywhere in the world, the fees to receive the card (cost of the card + shipping) how do you request the card, can it be used internationally without limitation (it would make sense since this solution is for international customers, but US banks tend to be very strict regarding sending wires or withdrawing money from ATM outside of the US), what are the daily/monthly ATM withdrawal limits, and any other useful information. Thank you
Long answer: it's a risk game, you may get away by showing that you have processes in place to manage this risk for open source projects:
* internal backup of the source tree.
* in-house skills to perform basic patching of the software if the development get discontinued.
* alternative solution and roll-out plan in case the development of your current solution gets discontinued.
* ...
Finally, risks can be accepted and someone ("the business") can sign-off on them. You don't have to remediate everything. It's just an awareness exercise for "the business".
Agree with this but I would also ask the auditor to be very specific about the risk that she believes your organisation is exposed to. If its a specific concern about the suitability/support of certain tools in use in your infrastructure, you can respond to/address those. In particular, I would make sure that the risk is clear about the impact it could have if an OSS project was discontinued (as the parent refers to): its unlikely to have an immediate impact as, by definition, you have a working instance of the tool and the source code so nothing stops working. In many ways this is comparable to the sort of escrow clauses that auditors sometimes look for in commercial support arrangements and which are often deemed acceptable mitigation for commercial products. She should also be clear about likelihood. In my experience (I've been an auditor for c18 years), it can be the case that auditors think about the doomsday scenario - e.g. ALL of the OSS projects you use close down - rather than the more likely scenario that one or maybe two go dark. Again, if she can articulate the specific risk it may be possible for you to respond to real likelihood of a key tool's project stopping (which would parent's approach already covered but which can be prioritised according to risk).
If however its a more general/vague concern about OSS support then you'll have a hard time dealing with it and acceptance may be the appropriate route.
