duan tran-email

Software Development Life Cycle

by with No Comment Software development

Software Development Life Cycle (SDLC) is a process used by the software industry to design, develop and test high-quality software. The SDLC aims to produce high-quality software that meets or exceeds customer expectations, reaches completion within times and cost estimates.
SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.

A typical Software Development Life Cycle consists of the following stages:

Stage 1: Planning and Requirement Analysis
Requirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys, and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility studies in the economical, operational, and technical areas.
Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.


Stage 2: Defining Requirements
Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved by the customer or the market analysts. This is done through an SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle.


Stage 3: Designing the Product Architecture
SRS is the reference for product architects to come out with the best architecture for the product to be developed. Based on the requirements specified in SRS, usually, more than one design approach for the product architecture is proposed and documented in a Design Document Specification.
This Design Document Specification is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget, and time constraints, the best design approach is selected for the product.


The Design Document Specification could consist of:
Architecture – Specifies programming language, industry practices, overall design, and use of any templates or boilerplate
User Interface – Defines the ways customers interact with the software, and how the software responds to input
Platforms – Defines the platforms on which the software will run, such as Apple, Android, Windows version, Linux, or even gaming consoles
Programming – Not just the programming language, but including methods of solving problems and performing tasks in the application
Communications – Defines the methods that the application can communicate with other assets, such as a central server or other instances of the application
Security – Defines the measures taken to secure the application, and may include SSL traffic encryption, password protection, and secure storage of user credentials
Prototyping – it is like one of the early versions of software in the Iterative software development model. It demonstrates a basic idea of how the application looks and works. This “hands-on” design can be shown to stakeholders. Use feedback o improve the application. It’s less expensive to change the Prototype phase than to rewrite code to make a change in the Development phase.


Stage 4: Building or Developing the Product
In this stage of SDLC, the actual development starts, and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high-level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.


Stage 5: Testing the Product
This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC. However, this stage refers to the testing only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.


Stage 6: Deployment in the Market
Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (User acceptance testing).
Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment.


Stage 7: Operations and Maintenance
At this point, the development cycle is almost finished. The application is done and being used in the field. The Operation and Maintenance phase is still important, though. In this phase, users discover bugs that weren’t found during testing. These errors need to be resolved, which can spawn new development cycles.
In addition to bug fixes, models like Iterative development plan additional features in future releases. For each new release, a new Development Cycle can be launched.

SDLC shows you what’s happening, and exactly where your development process can improve.

duan tran-email

What is Application Security Testing

by with No Comment SecuritySoftware development

Application security testing is the process of making applications more resistant to security threats, by identifying security weaknesses and vulnerabilities in source code.
AST started as a manual process. Today, due to the growing modularity of enterprise software, the huge number of open source components, and a large number of known vulnerabilities and threat vectors, Application security testing must be automated.


Static Application Security Testing (SAST)
Static Application Security Testing tools use a white box testing approach, in which testers inspect the inner workings of an application. Static Application Security Testing inspects static source code and reports on security weaknesses.
Static testing tools can be applied to non-compiled code to find issues like syntax errors, math errors, input validation issues, invalid or insecure references. They can also run on compiled code using binary and byte-code analyzers.

Dynamic Application Security Testing (DAST)
Dynamic Application Security Testing tools take a black-box testing approach. They execute code and inspect it in runtime, detecting issues that may represent security vulnerabilities. This can include issues with query strings, requests and responses, the use of scripts, memory leakage, cookie and session handling, authentication, execution of third-party components, data injection, and DOM injection.
Dynamic Application Security Testing tools can be used to conduct large-scale scans simulating a large number of unexpected or malicious test cases and reporting on the application’s response.


Interactive Application Security Testing (IAST)
Interactive Application Security Testing tools are the evolution of Static Application Security Testing and Dynamic Application Security Testing tools—combining the two approaches to detect a wider range of security weaknesses. Like Dynamic Application Security Testing tools, Interactive Application Security Testing tools run dynamically and inspect software during runtime. However, they are run from within the application server, allowing them to inspect compiled source code like Interactive Application Security Testing tools do.
Interactive Application Security Testing tools can provide valuable information about the root cause of vulnerabilities and the specific lines of code that are affected, making remediation much easier. They can analyze source code, data flow, configuration and third-party libraries, and are suitable for API testing.


Mobile Application Security Testing (MAST)
Mobile Application Security Testing tools combine static analysis, dynamic analysis and investigation of forensic data generated by mobile applications. They can test for security vulnerabilities like Static Application Security Testing, Dynamic Application Security Testing and Interactive Application Security Testing, and in addition address mobile-specific issues like jailbreaking, malicious wifi networks, and data leakage from mobile devices.


Software Composition Analysis (SCA)
Software Composition Analysis tools help organizations conduct an inventory of third-party commercial and open source components used within their software. Enterprise applications can use thousands of third-party components, which may contain security vulnerabilities. Software Composition Analysis helps understand which components and versions are actually being used, identify the most severe security vulnerabilities affecting those components, and understand the easiest way to remediate them.


Runtime Application Self-Protection (RASP)
Runtime Application Self-Protection tools evolved from Static Application Security Testing, Dynamic Application Security Testing and Interactive Application Security Testing. They are able to analyze application traffic and user behavior at runtime, to detect and prevent cyber threats.
Like the previous generation of tools, Runtime Application Self-Protection has visibility into application source code and can analyze weaknesses and vulnerabilities. It goes one step further by identifying that security weaknesses have been exploited, and providing active protection by terminating the session or issuing an alert.
Runtime Application Self-Protection tools integrate with applications and analyze traffic at runtime, and can not only detect and warn about vulnerabilities but actually prevent attacks. Having this type of in-depth inspection and protection at runtime makes Static Application Security Testing, Dynamic Application Security Testing and Interactive Application Security Testing much less important, making it possible to detect and prevent security issues without costly development work.