What’s your current approach to preventing data injection into your commands framework? Do you place more focus on secure coding practices, testing, patching, user input validation or something else altogether?
CIO in Retail, 10,001+ employees
More focus on secure coding practices and testing as a primary approach.Chief Information Security Officer in Healthcare and Biotech, 1,001 - 5,000 employees
We mostly focus on securing code, testing and patching etc. But now have taking few small step especially on the API site for data injection. Content you might like
CTO in Software, 201 - 500 employees
Without a doubt - Technical Debt! It's a ball and chain that creates an ever increasing drag on any organization, stifles innovation, and prevents transformation.We provide company-wide training57%
We only train certain departments/roles32%
We have a targeted individual training approach.9%
I am unsure how we handle security training.3%
230 PARTICIPANTS
Very likely3%
Likely42%
Moderately likely33%
Moderately unlikely10%
Unlikely7%
Very unlikely3%
Unsure1%
153 PARTICIPANTS
Patching is your last resort. That means something bad got in the wild. Think of it that your dev cycle starts with dev on the left and flows into production on the right. Patching in production is your most expensive endeavor. The further left in the cycle that you can catch the issue, the cheaper the resolution for your organization.
With all of this being said, the neat thing is we're in a world where soooo much of this can be automated in a CICD pipeline. So, it sounds like a lot but if you have a CICD pipeline, these tools can all be plugged in. Another interesting concept I'd read about around this idea is DevSecOps.
Lots of information but I had to cut myself off too - hope it all helps.