I Can’t See my Software Security Blind Spots

10804958454?profile=RESIZE_400xAccording to recent studies, developers spend more time maintaining, testing and securing existing code than they do writing or improving code.  Security vulnerabilities have a bad habit of popping up during the software development process, only to surface after an application has been deployed.  The disappointing part is that many of these security flaws and bugs could have been resolved in an earlier stage and there are proper methods and tools to uncover them.  Everyone makes mistakes, even developers. Software bugs are inevitable and are accepted as the "cost of doing business" in this field.

Any unfixed bugs in code are the lifeblood of attackers.  If they can find at least one bug in a system that can be exploited in the right way (i.e., a software vulnerability), they can leverage that vulnerability to cause massive damage, potentially on the scale of tens of millions of dollars as we seen in cases on the headlines every year.   And even when it comes to less serious vulnerabilities, fixing them can be very costly especially if a weakness is introduced much earlier in the SDLC due to a design flaw or a missing security requirement.

Why is the current approach to software security falling short?

  1. Too much reliance on tech (and not enough on humans)

Automation and cybersecurity tools are supposed to reduce the workload for developers and application security staff by scanning, detecting, and mitigating software vulnerabilities, however:

While these tools do contribute to cybersecurity efforts, studies show that they can only discover 45% of overall vulnerabilities.

They can also produce "false positives," leading to unnecessary concern, delays, and rework

  1. The DevSec disconnect

The DevSec disconnect refers to the well-known tension between dev teams and security teams due to different (and often conflicting) priorities when it comes to new features and bug fixes.

As a result of this friction, 48% of developers end up regularly pushing vulnerable code into production. Vulnerabilities discovered later in the development cycle often do not get mitigated, or end up creating extra costs, delays, and risks further down the line. These are the consequences of short-term thinking: ultimately, it would be better to fix the problem at the source instead of spending time and resources on finding code flaws later in the software development lifecycle.

  1. Monitoring your supply chain but not your own software

Another common mistake is focusing solely on the software supply chain security and only addressing known vulnerabilities in existing software products and packages listed in the famous Common Vulnerabilities and Exposures database or the National Vulnerability Database. Dealing with any vulnerabilities in third-party components, your dependencies, or the operating environment is essential, but this won't help you with vulnerabilities in your own code.  Similarly, monitoring potential attacks via intrusion detection systems (IDS) or firewalls followed by incident response is a good idea and is recognized by OWASP Top 10 as a necessity but these activities just deal with the consequences of cyberattacks rather than the cause.

Your cybersecurity is only as strong as your weakest link. Software development is not an assembly line job, and despite all predictions it will not be fully automated anytime soon. Programmers are creative problem-solvers who need to make hundreds of decisions each day as they write code, because software development is a type of craftsmanship.

Processes, standards, and tools can help foster and reinforce best practices, but if a developer doesn't know about a particular type of bad practice, they are likely to keep committing the same mistake (and introducing the same type of vulnerability in the code) over and over again.

Six tips for empowering secure coding:

The number of newly discovered vulnerabilities is rising and the threats posed by malicious cyber actors are steadily getting more sophisticated. Most organizations start implementing a secure development lifecycle after an incident, but if you ask us when you should start, the answer, of course, will always be the sooner, the better. That is because when it comes to critical vulnerabilities, even hours can mean the difference between no lasting damage and a financial disaster.

  1. Expand security perspective to early phases of development. Relying on DevSecOps-style security tool automation by itself isn't enough, you need to implement real culture change. SAST, DAST, or penetration testing is on the right in the SDLC; shift left towards the beginning of the software development lifecycle for more comprehensive coverage.
  2. Adopt a secure development lifecycle approach. MS SDL or OWASP SAMM for example will provide a framework for your processes and act as a good starting point for your cybersecurity initiative.
  3. Cover your entire IT ecosystem. Third-party vulnerabilities pose a huge risk to your business' cybersecurity, but your own developers may be introducing problems to the application, too.  You need to be able to detect and resolve vulnerabilities on premises, in the cloud, and in third-party environments.
  4. Move from reaction to prevention. Add defensive programming concepts to your coding guidelines. Robustness is what you need. Good security is all about paranoia.
  5. Mindset matters more than technology. Firewalls and IDSs won't protect your software from hackers by themselves; they just deal with the consequences of already existing vulnerabilities.  Tackle the problem at its root: the developers' mindset and personal accountability.
  6. Invest in secure code training. Look for a resource that covers a wide range of programming languages and provides thorough coverage of secure coding standards, vulnerability databases, and industry-renowned critical software weakness types. Hands-on lab exercises in developers' native environments are a huge plus for getting them up to speed quickly and bridging that pesky knowing-doing gap.

Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization.     For questions, comments or assistance, please contact the office directly at 1-844-492-7225, or feedback@wapacklabs. com    

Weekly Cyber Intelligence Briefings:

Weekly Cyber Intelligence Briefings:

REDSHORTS - Weekly Cyber Intelligence Briefings

https://attendee.gotowebinar.com/register/5504229295967742989

Sources:

https://tidelift.com/subscription/managed-open-source-survey

https://owasp.org/www-pdf-archive/OTGv4.pdf

https://info.veracode.com/survey-report-esg-modern-application-development-security.html

https://thehackernews.com/2022/09/the-ultimate-security-blind-spot-you.html

 

 

E-mail me when people leave their comments –

You need to be a member of Red Sky Alliance to add comments!