Software Certification is an assurance that a product conforms to specified characteristics. The main objective of software certification is to improve the reliability and security of the software systems. In this article, I have presented software certification framework which is a combination of joint certification techniques. With these two techniques, two models namely software process assessment and certification model and software product certification model have been developed. I also gave an overview of software verification artefacts, software metrics and system software, certified software, modular reasoning and separation logic, certified compilation and lightweight formal methods.
Introduction
In today’s world, software has become a crucial part in daily working environment. Unlike other engineered artefacts, software is one of the weak artefacts as it rarely does exactly what we expect. Sometimes, even well tested software behaves in an unexpected way such as crashing or corrupting information etc. This can be reduced with the help of software certification. Software certification artefacts offer organisations more confidence about software. A software certificate became a powerful weapon for software customers to test the reliability of software in different environments. Software certification demonstrates the reliability and security of the software systems. There exists a software certification framework which is a combination of two different certification techniques. From this framework, two models namely software process assessment and certification model (SPAC) and software product certification model (SCfM_Prod) have been implemented. These certification models not only offer a mechanism for assessment and certification but also guarantee continuous improvement in software quality.
Software certification
Software Certification is an assurance that a product is definite with specific characteristics. Generally, assurance is provided by a third party organisation. Certification and quality are two interrelated terms to be considered one in another. The benefit of certification in software industry will highlight more on standard in the processes and thus it helps to increase the software quality.
Software Certification Framework:
Software Certification framework has been shown in figure 1 which is a combination of joint certification techniques to produce a candidate software product. For a software product, the certification level can be obtained by two different certification approaches which are classified as process and product approach. This Software Certification framework is apt to assess and certify the software product. There are various approaches to certify the software product. One of them is collaborative perspective approach. It consists of developers, users and also an independent assessor. When compared to other approaches, the collaborative perspective approach has following advantages:
It eliminates bias assessment by an independent assessor.
It removes unfairness evaluation of the product.
As the team is familiar with both the environment and the product, it accelerates the process.
C:\Users\Swetha Alluri\Pictures\SC Framework.jpg
With two different techniques specified in the framework, two models namely SPAC and SCfM_Prod have been implemented. Each model is dealing with different procedures in the process of certification and has separate quality criteria. The two models are briefly described below.
Software Process Assessment and Certification Model (SPAC)
SPAC is a certification model which is performed by development process. The primary goal of SPAC model is to carry out the software development process more efficiently so that it can meet the quality criteria, budget and deliver the product on time. SPAC model is represented in figure 2.
C:\Users\Swetha Alluri\Pictures\SPAC.jpg
SPAC model consists of seven components as shown in the above figure. The functions of seven components are:
Process Quality Factor: It is a first component of SPAC which mainly focuses on what to be measured. It identifies five factors that focus on the quality of software. The five factors are:
Process: It consists of three activities namely development, support and management.
People: This measures based on experience, user involvement, skill, knowledge, leadership and management responsibility.
Environment: This measures the safety and comfort issues in the work place.
Development technology: This measures the process, procedure, methods, tools and techniques.
Project constraint: It is the aspect of quality that measures the budget and the product delivery time.
Candidate Software: This is the completed software that is prepared to be delivered to the customers. The development process data is gathered by observing the work environment, reviewing the artefacts that are produced in the development process and by interviewing key personnel.
Assessment Team: The assessment of the software is carried out by using a collaborative approach. Project manager, developers and the independent assessor will not be included in the assessment team. The team leader must be an expert in software quality and software engineering.
Assessment and Certification process: This mainly consists of three phases namely preparation, execution and post assessment. After completion of the phases, these are decomposed into sixteen activities that provide guidance to the certification process.
Quality Level Component: It finds the quality level of the completed software.
Certification Level Component: It determines the certification level of the software based on certification requirement.
Repository: It stores all the information and the results obtained from assessment and certification process to utilise for future work.
This model contains two quality indexes. One is Quality assessment level which is focussed to discover the achievements that are obtained for each attributes and metrics in the assessment exercise and the other one is certification level which is used by candidate software developer group to measure the overall performance of the completed software process development.
Software Product Certification Model (SCfM_Prod)
SCfM_Prod is a certification model which is performed by product quality perspective. In this model, the software is certified based on the assessment of end product which is independent of the development process. This model includes six main components classified as:
Pragmatic Quality Factor (PQF): It is the quality certification guidelines used to measure the software product quality. Considering the quality attributes that are mentioned in ISO 9126 model, software product certification model define two sets of attributes classified as behavioural and impact attributes. The behavioural attributes include high level software quality features such as efficiency, integrity, usability, portability, reliability, maintainability and functionality. Based on the significance during the assessment, the quality attributes are grouped into three different levels known as low, medium and high that are assigned with corresponding weight factors. The classification of attributes and its weight factors are shown in table 1. The second attribute i.e. impact attribute deals with user requirements, expectation etc. This attribute include performance, trustworthiness, user satisfaction and acceptance measures.
C:\Users\Swetha Alluri\Pictures\table 1.jpg
Product Criteria: This component offers various services for weight factors and selection of criteria. This enables the users to select the required quality attributes of their interest so that it can meet the requirements of the organisation. This component is also flexible in the certification exercise.
Certification Team: Includes developer, user and independent assessor. These three individuals perform the certification process collaboratively.
Certification Specification: This component explains the activities that are performed in the certification exercise such as process, formulas, algorithm and reporting format.
Certification Representation Method: It performs Certification-mapping process of the candidate software product to obtain its associated level of certification. In this model, the ranking of certification level is flexible and the owner of the software product and the organisation may change the classification levels based on the development of the organisation. The certification levels are classified as excellent, good, acceptable and poor. The certification level is identified based on the TQP value. TQP is the score value that is obtained by performing the certification exercise. The TQP score, its corresponding certification level, status and description are shown in table 2.
C:\Users\Swetha Alluri\Pictures\table 2.jpg
Repository: As in SPAC model, it stores all the required information and results obtained from assessment and certification process for future analysis.
Software Verification Artefacts
The main goal of software verification is to guarantee that the software satisfies all the requirements. The software verification artefacts are depicted in figure 3. It describes the main artefacts involved in the software verification process. It gives a brief outline of software verification. Software verification artefacts are divided into three layers. The first layer includes ideas and requirements. User expectations, estimate image of how the software works, requirement specifications and the design document comes under this layer.
C:\Users\Swetha Alluri\Pictures\Software verification artefacts.jpg
The middle layer consists of formal logic and machine-checkable artefacts. In this layer the requirements are translated into properties of formal system specifications. The system specification includes the description of how the system executes, behaves or how the state mutates over time. The bottom layer includes the physical artefacts such as transistors, electrical charges, microchips and the environment where the machine operates. Example of physical artefact could be program source code which is generally the lowest level of software development process.
Software Metrics and System Software
As the software grows larger, various issues such as privacy, reliability and security of software systems have become a major concern. Software metrics is the measure of properties of software development process. The main goal of software metrics is to identify and measure the critical parameters that affect the software development. Every customer would like to have error-free computer software. It has been extremely difficult for developers to produce reliable software systems efficiently. The life cycle of software consists of series of analysis, design, coding, testing and maintenance phases. The testing and maintenance phases play a vital role in the software life cycle and hence there should be efficient management during these phases to produce highly reliable software.
On a daily basis, millions of people perform transactions through internet and ATM and also send emails. Software security has become a major concern in day-to-day life. It plays a vital role because many functions are fully dependent on the software. So, security must be taken into consideration during the entire software development life cycle. Twenty one software security rules are proposed to implement the security in the software which is depicted in figure 4. For clear description of the twenty one security rules see ref. After applying these twenty one security rules to a real life projects, the level of risk is minimised to 40.5% (REF)
C:\Users\Swetha Alluri\Pictures\security rules.jpg
For proper implementation of security beginning from the requirements phase, all the people who are involving in the software development life cycle must be aware of latest critical software security issues. The implementation mechanism of twenty one software security issues throughout the software development life cycle is shown in figure 5. Requirements engineer, software designer, programmer, software test engineer, implementation engineer and maintenance engineer must perform their respective roles focusing on all twenty one software security rules.
C:\Users\Swetha Alluri\Pictures\Security rules implementation.jpg
Advantages of implementing the above twenty one software security rules right from the first phase in software development lifecycle:
The most appropriate security mechanism will be implemented by requirements engineer in requirements phase.
Most secure software architecture can be designed by designers.
It will help the programmer to develop more secure code.
For testing the software, the test engineers will be able to select the suitable tools and techniques keeping in mind the security rules.
It will help the implementation engineer to configure and run the software much more securely.
Secure maintenance plan will be developed by maintenance engineers so that the software can be adapted to a more secured environment.
Coming to system software, for operating systems, reliability is a vital requirement. Recent research has shown that several operating systems are still containing number of bugs even after careful design and testing. To avoid this, there are three methods namely static methods, formal verification and runtime checking. For a full description of these methods see ref. These methods are mainly used for automated detection of bugs.
However, compiler algorithms are used to assist software development, improve its performance and even detect the software defects. The compiler field is highly tangled with several disciplines such as software engineering, programming languages, computer architecture and computer security. The compiler is mainly focused on the use of high-level languages. Today, most software is written in high-level languages. Compilers play a vital role in implementing software security and reducing the vulnerabilities leading to loss of privacy. The code that is generated by compilers is an essential feature of software verification.
Certified Software
Certified software consists of a machine executable C program and a rigorous formal proof that the software is bug free with respect to a particular specification. Both the formal proof and the specification are typically written using a general purpose mathematical logic. Certified software cannot be practical because any real software must rely on its underlying operating system which is low-level and complex to be provable. However, there have been many techniques that are applied to verification of low-level code such as proof carrying code, certified compilation etc.
Components of a certified framework
A certified framework consists of five components as shown in figure 6.
Certified software: It includes machine code and formal proof.
Formal machine model: Provides operational semantics for machine instructions.
Formal software dependability claim: Includes security, safety property and functional specification for correctness.
Underlying mechanised metalogic (not shown): Used for coding machine-level programs, specifications and proofs.
Proof checker: Checks the validity of all proofs that follow the inference rules of metalogic.
C:\Users\Swetha Alluri\Pictures\components of certified framework.jpg
Advantages of Certified Software
The dependability of software can be verified independently in an extremely reliable way.
If the software community agree on a single metalogic, then certified software system would provide an excellent framework for building dependable software components.
Unlike higher-level programming languages, it places no restrictions on how the programs are developed and the efficiency of its code.
It encourages the best practices both in software engineering and program verification.
It also decouples the tools from proof checking infrastructure for development of the programs and proof construction.
It also improves the maintainability of underlying software system.
Modular reasoning and Separation logic for making program verification scale
Modular reasoning is the key technique involved in making program verification scale. The programmers follow top-down approach so that it would benefit the development of certified software system. They first work out the requirement specifications and design, then decompose the total system into smaller modules, refine specifications into actual implementation and finally certify individual components and link the entire modules together to form a complete system.
However, separation logic is another critical technique in making program verification scale. Traditional Hoare logics make use of program specifications with randomly large footprints. Separation logic promotes local reasoning using small footprint program specifications i.e. each module specifications should refer only to data structures. By specifying the separation of heap and several resources, separation logic provides yet powerful inference rules for shared mutable data structures. However, Concurrent separation logic also applies same idea to shared memory concurrent programs by assuming the invariant that there exists partition of memory among different entities and each entity will be able to access only its own part of memory. This invariant has two important points that are to be considered. First, the partition is logical so that the programmers do not need to change the physical structure of machine and this logical partition can be imposed through separation logic primitives. Secondly, the partition is not static. By transferring the ownership of memory between the entities, it can be altered dynamically during program execution. A shared memory program can be certified under concurrent separation logic as it manipulates its private heap and for accessing shared memory, it invokes an atomic procedure that transfers resources between shared and local heap. As recent efforts have extended concurrent separation logic with guarantee reasoning, the lock-free concurrent code can also be certified using small footprint modular specifications.
Certified Compilation
The main objective of certifying compilation is to increase compiler robustness and program safety. A certifying compiler converts a source language program into object code and also produces a certificate. A component named verifier checks the object code and certificate and verifies if the object code really satisfies the required properties. Various properties including memory safety, security and control safety can be verified. To produce fast and secure programs, it is necessary to merge certifying compilation with run-time code generation. To achieve this, two new languages Cyclone and TAL/T are used. Cyclone is a type safe dialect of C where as TAL/T is a type safe assembly language. To enhance compiler correctness, Cyclone is implemented as a certifying compiler that helps to correct compiler bugs. Here, Cyclone is compiled into TAL/T language. The overview of Cyclone compiler is shown in figure 6. The Cyclone compiler is built based on two systems, Tempo analyzer and Popcorn certifying compiler. In the first phase, C program is transformed into Cyclone program that employ run-time code generation by making use of tempo analyzer. Since C is not a type safe language, the first phase may not produce a well typed Cyclone program. Hence, in second phase Cyclone program is compiled into TAL/T program by using popcorn. The front end of popcorn is extended for handling Cyclone programs and its back end is modified so that it outputs TAL/T. Finally, in third phase, the TAL/T program is verified, assembled and then linked into an executable object code. This three phase Cyclone compiler is a flexible user interface as it allows the programs that are written in C, Cyclone or TAL/T. Even the user may simply write a C program and can handle the rest to the system.
C:\Users\Swetha Alluri\Pictures\certified compilation.jpg
Lightweight Formal Methods
For certified software systems, high-level program verification is not always required. Most systems are made from modular components at various levels of abstraction. The runtime system components and the kernel are at lowest levels where as the components with restricted structure are at highest levels. The restricted structure may use type-safe, high-level programming languages or even C programs. Lightweight formal methods such as specialised program logic, high-level type system and static analysis can help safety properties with programmer effort; error messages from static analyser and type checker generally give accurate feedback in the programming process. Sometimes, these safety properties can even act as security properties. One such example is: Module X cannot access the private variables of module Y, except through the public methods that are provided by Y. Lightweight formal methods can also be used to reduce the cost of producing certified software. A programmer will be able to make the proof witness automatically so that they can be linked with certified low-level kernel and runtime system components.
Conclusion
