In recent years, the software development paradigm has evolved under the influence of several key trends. The wider adoption of Agile and DevOps practices has increased the pace in which applications are packaged, built, and shipped to production. The fast pace of digitalisation in enterprises has created a push for acquiring or developing applications to serve and support their value chains. An unprecedented acceleration of that pace is observed ever since the Covid-19 pandemic started. The ever increasing reliance of business and societal transactions on applications has led to high profile security breach cases which consequently were attributed to security negligence during the early stages of software development [1,2].
In this environment, the new mantra fοr both security and business leaders is to shift security left in the software development lifecycle. Security leaders want to be proactive and spot security weaknesses as early as possible to understand their full extent and work together with the development teams to apply fixes. Business leaders want to prevent additional costs introduced when fixing bugs comes later in the development lifecycle while avoiding any reputational damages from security incidents.
The IoTAC project has a primary goal to deliver a novel, secure and privacy-friendly IoT architecture that shall empower the development and operation of more resilient IoT service environments. A particular aspect of ensuring such resilience is monitoring and evaluating application security in the implementation phase of the software development lifecycle.
IoTAC methodology has been designed with the ‘shift left’ goal in mind to ensure that valuable insights about security during the implementation phase are produced and typical challenges of having security and development teams working together in that phase are addressed.
The methodology during the implementation phase builds on:
- Secure Coding Practices
- Security Unit Testing
- Static Application Security Testing
- DevSecOps automation
Software programmers must code securely but they need to do so by using consistent and appropriate guidelines. In the context of the IoTAC project, developers shall work and follow both technology-agnostic security coding practices [3] while leveraging technology-specific security frameworks and libraries.
Security unit testing shall complement the secure coding efforts of developers and further promote the ‘shift left’ goal. Development and execution of security unit tests cases shall leverage OWASP’s Application Security Verification Standard (ASVS) [4] that provides developers with a list of requirements for secure development and a basis for testing technical application security controls.
To further support secure coding, IOTAC methodology incorporates Static Application Security Testing (SAST) on the Integrated Development Environment (IDE) level and on the code repository level. In the general case, SAST facilitates the analysis of source code or compiled versions of code in order to identify security flaws. The main advantages from executing SAST are the automatic identification of “known bad” code, the precision in pinpointing “known bad” in the source code base and scalability to run analyses across multiple software and code bases [5]. SAST in the IDE gives software developers real-time individual feedback, helping them fix issues before they commit their code. SAST on the code repository level is performed against a shared codebase increasing the depth and breadth of the checks, helping to reveal more tricky security issues, and enforcing sets of conditions against which code branches are measured. All these sets of conditions are abstracted into quality gates that signal a pass or fail result [6].
In order to enable the flexible collaboration between development, operations, and security teams towards releasing frequently integrated but secure versions of software in the IOTAC project, a DevSecOps approach is adopted. This approach integrates the security practice of SAST in Continuous Integration (CI) and Continuous Delivery process so that security and compliance artifacts are automatically generated.
Based on the above elaboration, Figure 1 illustrates the IoTAC methodology to instil security in the implementation phase of software engineering.
Figure 1: Security during implementation – IoTAC Methodology
- The SolarWinds hack timeline: Who knew what, and when? https://www.csoonline.com/article/3613571/the-solarwinds-hack-timeline-who-knew-what-and-when.html
- D-Link Agrees to Make Security Enhancements to Settle FTC Litigation https://www.ftc.gov/news-events/press-releases/2019/07/d-link-agrees-make-security-enhancements-settle-ftc-litigation
- OWASP Secure Coding Practices
- OWASP Application Security Verification Standard v4.0.2
- Source Code Analysis Tools https://owasp.org/www-community/Source_Code_Analysis_Tools
- Quality Gates – https://docs.sonarqube.org/latest/user-guide/quality-gates/
