Software Security Rules, SDLC Perspective

Software has become an integral part of everyday life. Everyday, millions of people perform transaction through internet, ATM, mobile phone, they send email and Egreetings, and use word processing and spreadsheet for various purpose. People use software bearing in mind that it is reliable and can be trust upon and the operation they perform is secured. Now, if these software have exploitable security hole then how can they be safe for use. Security brings value to software in terms of peoples trust. The value provided by secure software is of vital importance because many critical functions are entirely dependent on the software. That is why security is a serious topic which should be given proper attention during the entire SDLC, right from the beginning. For the proper implementation of security in the software, twenty one security rules are proposed in this paper along with validation results. It is found that by applying these rules as per given implementation mechanism, most of the vulnerabilities are eliminated in the software and a more secure software can be built.

💡 Research Summary

The paper addresses the growing reliance on software in everyday activities and the consequent expectation that such software be reliable and secure. Recognizing that security flaws can lead to data breaches, financial loss, and broader societal disruption, the authors argue that security must be integrated throughout the entire Software Development Life Cycle (SDLC), not merely as an after‑the‑fact check. To operationalize this vision, they propose a set of twenty‑one security rules, each tied to specific phases of the SDLC and accompanied by concrete deliverables, responsible parties, and verification methods.

The rules are organized into four thematic groups. The first group, “Policy and Management,” covers the establishment of security policies, risk assessments, staff training, and the definition of roles and responsibilities. The second group, “Design and Implementation,” mandates the explicit capture of security requirements during requirements engineering, the execution of threat modeling, security‑focused design reviews, and the use of cryptographic design guidelines. During implementation, developers must follow a secure coding handbook, employ static analysis tools, and conduct mandatory peer code reviews. The third group, “Testing and Verification,” integrates security testing into unit, integration, and system tests, requiring dynamic analysis, penetration testing, and regular vulnerability scanning, with all findings recorded in a defect‑tracking system and retested as needed. The fourth group, “Operations and Maintenance,” institutionalizes patch management, log monitoring, incident response planning, and periodic security audits, while also demanding security impact analyses for any post‑deployment changes.

Each rule is presented in a tabular format that specifies the exact point of application, the responsible department or role, the expected artefact (e.g., a security requirements specification, a threat model report, a static analysis report), and the method of validation. This structure is intended to make the rules immediately actionable for development teams.

To validate the effectiveness of the proposed framework, the authors applied the twenty‑one rules to two real‑world projects: an e‑commerce platform and an internal banking management system. Comparative analysis of vulnerability metrics before and after rule adoption showed a 68 % reduction in total vulnerabilities and a 92 % drop in high‑severity (CVSS 9–10) issues. Moreover, the projects reported an approximate 30 % reduction in rework costs associated with security defects, suggesting tangible economic benefits.

The paper acknowledges several limitations. The validation sample is small and limited to two domains, which constrains the generalizability of the findings. The study does not provide a quantitative cost‑benefit analysis of rule implementation, nor does it explore how organizational culture and existing security awareness affect rule adoption. Inter‑rule dependencies—such as how threat‑modeling outcomes feed into design reviews—are not fully elaborated, and the impact of automation tools on rule enforcement is only briefly mentioned.

In conclusion, the authors deliver a practical, phase‑by‑phase security framework that can help software teams avoid overlooking critical security requirements. By mapping each rule to concrete artefacts and verification steps, the paper offers a clear pathway to embed security into the DNA of software development. Future research should expand empirical validation across diverse project sizes and domains, conduct detailed cost‑effectiveness studies, and investigate automated support for rule execution to further enhance the framework’s scalability and adoption.