There are hundreds of companies that offer cyber security platforms, tools, pentest services, GRC, IDS/IPS & SEIM implementations.
Instead of focusing on discovering and reporting vulnerabilities, Panaton offers source-code level security remediation services.
We instrument our clients’ codebases with automated security vulnerability scanning and fix discovered issues by working in parallel with our client’s software teams, so that planned feature releases are not delayed while working on security concerns.
With over 20 years of experience in core C, C++, Java and .NET programming, we address your lists of security issues and vulnerability findings, and put in place the often missing security components in existing DevOps processes.
Our leverage is own unique expertise with embedded and IoT systems across various platforms from NXP, Freescale, Odroid, TI, Ricoh, Konica-Minolta and Fujitsu.
Source-code security Remediation Engagement Process
- Start by identifying source code repositories and the programing languages and build tools used. Eliminate from scope code that is obsolete, non-essential or deemed to be of low value.
- Based on the results from (1) select appropriate automatic analysis tools, or configure client-owned ones for the project.
- Perform the analysis – both automation as well as manual review, including documentation review.
- Eliminate false positives and non-essential findings and assemble report.
- Cooperatively review report details and create a remediation plan. Design an integration of static code security analysis and 3rd party patch cadence as part of the standard DevOps process.
- Reconcile remediation plan against already committed delivery timelines, available internal resources and budgets.
- Perform code update / remediation & merge to appropriate branches.
Why Outsource Code Security?
Not just the “new” and “cool” tools:
- Security costs extra development time. How can you address security without having to reassess your product delivery commitments?
- Most programmers are not security people; they simply don’t often think like an attacker does.
- Most security people are not programmers. Many CISOs are MBAs, sometimes, but not always with some security certification “letters” after their titles. 90% of “certified” information security people are in fact NOT software engineers and the majority come from sysadmin and network engineering backgrounds.
- Security education is deficient. There is no curriculum that addresses computer security in most schools. Even when there is a computer security curriculum, they often don’t discuss how to write secure programs as a whole. Many such curriculum only study certain areas such as cryptography or protocols. These are important, but they often fail to discuss common real-world issues such as buffer overflows, string formatting, and input checking.
- Most programming books/classes do not teach secure/safe programming techniques.
We are not just users of core technology, but also tool builders:
- No one uses formal verification methods.
- All “modern” platforms are written in C – Apache, Node.js, MySQL, Java, PHP, etc. BUT C/C++ are unsafe language(s), and the standard C library string functions are unsafe.
- Modern programmers rarely think “multi-user.” They assume request/response session isolation and believe that “multi-user” comes “for free”.
- Programmers are human, and humans are lazy. Thus, programmers will often use the “easy” approach instead of a secure approach – and once it works, they will avoid fixing it later.
- Most computer security models are terrible.
- There is lots of “broken” legacy software. Fixing this software (to remove security faults or to make it work with more restrictive security policies) is difficult to impossible.
- Like an external audit, or PCI certification, we would expect independents to deliver more objectivity.