DEV Community: Syed Mohammad Ibrahim

Code Review Exercises That Actually Work: Python Edition (Junior to Senior)

Syed Mohammad Ibrahim — Thu, 08 May 2025 15:00:00 +0000

In the last post, we focused on Java and how to evaluate code review skills across different levels of engineering experience. In this post, we shift gears to Python, a language known for its simplicity—and sometimes the unintended complexity that follows.

This post includes:

A Python code review style guide to share with candidates
Three code review examples (junior, mid, and senior)
Key things for interviewers to evaluate beyond syntax

Why Code Reviews in Python Interviews Matter

Python is deceptively simple. Bad code often works, until it scales or needs to be maintained. A good Python developer:

Writes readable, idiomatic code
Avoids hidden performance issues
Uses standard libraries effectively
Knows the tradeoffs of dynamic typing

Python Style Guide for Code Review Exercises

This style guide should be shared with interviewees at the beginning of the exercise:

✅ Code Style & Structure

Follow PEP 8 for naming, spacing, and line length
Use meaningful variable/function names
Avoid deep nesting and large functions

🔒 Error Handling

Use specific exceptions
Avoid bare except: blocks
Log or re-raise errors when appropriate

📦 Code Organization

Separate logic from I/O
Avoid hardcoded values
Minimize global state

🧪 Testability

Use functions with clear input/output
Write code that can be unit tested easily

🧼 Clean Code

Remove unused imports/variables
Prefer list comprehensions over manual loops (when readable)
Use built-in functions where appropriate

Junior-Level Code Review Example

Code Snippet:

def process_data(data_list):
    for item in data_list:
        if "@" in item:
            print("Email:", item)
        else:
            try:
                num = int(item)
                print("Number:", num * 2)
            except:
                print("Other:", item)

Issues to Spot:

Bare except block (catches everything)
No input validation
Uses print statements instead of return/log
Function is not reusable/testable

Follow-up Prompt:

Refactor this into smaller functions. Replace print with return values or logging. Improve exception handling.

Mid-Level Code Review Example

Code Snippet:

import json

def save_user_info(user_id, data):
    file_name = "user_" + str(user_id) + ".json"
    with open(file_name, "w") as f:
        f.write(json.dumps(data))

Issues to Spot:

No error handling for file I/O
Could use json.dump() instead of write(json.dumps(...))
Filename construction could be unsafe (injection risk)
No file existence or overwrite handling

Follow-up Prompt:

Refactor with exception handling and safer filename logic. How would you make this testable and secure?

Senior-Level Code Review Example

Code Snippet:

class ReportGenerator:
    def __init__(self, db):
        self.db = db

    def generate(self, report_type):
        users = self.db.query("SELECT * FROM users")
        if report_type == "summary":
            return self._summarize(users)
        elif report_type == "full":
            return self._generate_full_report(users)
        else:
            print("Invalid report type")

    def _summarize(self, users):
        return {"total": len(users)}

    def _generate_full_report(self, users):
        return users

Issues to Spot:

No input validation or report_type enforcement
Logic for DB query is tightly coupled
print() for error, instead of raising/logging
No logging or observability hooks
Could use Enum or constants for report_type

Follow-up Prompt:

How would you improve separation of concerns here? How would you test the report logic without a real DB?

Interviewer Tips

Use open-ended prompts: "What assumptions did you make?", "Would this scale?", "How would you test this?"
Look at how they reason through refactoring — not just what they fix
Focus on communication, understanding of tradeoffs, and clarity of explanation

What’s Next

In the next posts, we’ll dive into JavaScript, Go, and other languages to show how to scale this model across stacks and seniority.

This series is about designing interviews that feel like working with a great teammate — not jumping through academic hoops.

Code Review Exercises That Actually Work: Java Edition (Junior to Senior)

Syed Mohammad Ibrahim — Tue, 06 May 2025 15:00:00 +0000

In Part 1 of this series, we explored a practical, respectful approach to engineering interviews - focusing on real-world skills like code reviews, GitHub project walkthroughs, and collaborative coding.

In this post, we'll dive deeper into the code review portion of the interview. You'll get:

A neutral Java code style guide to use during interviews
Three code review examples, tailored for junior, mid-level, and senior candidates
Tips for interviewers on how to run this part effectively

Why Code Reviews Belong in Interviews

Code reviews aren't just about syntax or formatting. They uncover how a candidate:

Thinks about design and readability
Communicates technical feedback
Prioritizes bugs, maintainability, and best practices
Balances tradeoffs and pragmatism

It's one of the most real-world ways to assess software engineers - and works across all levels of experience.

Java Style Guide for Code Review Exercises

This is a neutral guide to share with candidates during the exercise. It helps structure their review without giving away the "answers."

✅ Code Style & Structure

Use descriptive class and method names
Break down large methods into smaller, testable pieces
Follow consistent indentation and spacing

🔐 Exception Handling

Catch only specific exceptions
Don't suppress or swallow errors silently

🧼 Clean Code

Remove unnecessary code or comments
Use named constants instead of magic numbers/strings
Avoid duplicating logic

🔍 Input & Output

Minimize direct System.out.println()
Separate core logic from I/O when possible

🚦 Testability

Make code easy to unit test
Aim for pure functions and clear input/output boundaries

Junior-Level Code Review Example

Code Snippet:

public class UserDataProcessor {
    public static void process(String[] args) {
        for (int i = 0; i < args.length; i++) {
            String s = args[i];
            if (s.contains("@")) {
                System.out.println("Email: " + s);
            } else {
                try {
                    int n = Integer.parseInt(s);
                    System.out.println("Number: " + (n * 2));
                } catch (Exception e) {
                    System.out.println("Other: " + s);
                }
            }
        }
    }
}

What to Look For:

Vague method name (process)
Overuse of System.out.println()
Poor exception handling (catch (Exception e))
No input validation or testability

Optional Follow-up Prompt:

Now refactor the code to improve clarity and maintainability. Feel free to break it into smaller methods and add input validation.

Mid-Level Code Review Example

Code Snippet:

public class FileLogger {
    public void logMessage(String level, String message) {
        try {
            FileWriter writer = new FileWriter("log.txt", true);
            writer.write(level + ": " + message + "\n");
            writer.close();
        } catch (IOException e) {
            // ignore
        }
    }
}

What to Look For:

No resource management (FileWriter should use try-with-resources)
Swallowed exception with no logging or rethrow
No separation between formatting and writing
Hardcoded file path

Follow-up Prompt:

Refactor this to follow SOLID principles and Java best practices. Consider testability and error handling.

Senior-Level Code Review Example

Code Snippet:

public class NotificationService {
    private List<User> users;

    public void notifyUsers(String message) {
        for (User user : users) {
            if (user.getEmail() != null) {
                EmailSender.send(user.getEmail(), message);
            }
        }
    }
}

What to Look For:

Tight coupling to EmailSender (static call)
No abstraction/interface for notification method
No error handling or delivery guarantees
No logging or observability
Threading/scalability not considered

Follow-up Prompt:

Refactor this to support future extensions (e.g., SMS, push notifications). Discuss design tradeoffs and test strategy.

Tips for Interviewers

Use open-ended prompts after the review:
- What would you change first?
- Is this code testable? Why or why not?
- Would this scale in a production system?
Match the complexity to the candidate's level
Don't judge by what they missed - focus on how they think, communicate, and justify decisions

Coming Up Next: Python, JavaScript, and More

This is just the beginning. Future posts will bring code review examples in other languages, helping teams run more effective interviews regardless of tech stack.

Rethinking Tech Interviews: Real Skills, Real Projects, No Bullshit

Syed Mohammad Ibrahim — Sun, 04 May 2025 23:56:32 +0000

Introduction

Let’s be honest — most software engineering interviews suck.

They’re filled with algorithmic trivia, abstract whiteboarding, and awkward “culture fit” questions that have nothing to do with the actual job. The result? Interviews that waste time for everyone and still fail to identify great engineers.

This blog is for both interviewers and interviewees — whether you’re designing a hiring process or preparing for one. The goal is to make interviews practical, time-efficient, and focused on what truly matters: real-world engineering skills.

What follows is a no-nonsense framework based on real projects, meaningful collaboration, and practical coding. It respects your time, cuts the fluff, and gives you real signal — fast.

1. Start with a GitHub (or GitLab) Project Walkthrough

What to do:

Ask the candidate to walk through a personal or professional project they're proud of. Dive deep into:

The why behind the project
Their architecture or design choices
Real implementation challenges and how they solved them

Example prompts:

“What tradeoffs did you make here?”
“Would you change anything about this design today?”
“How did you test this module?”

Why it works:

You’re evaluating practical experience, ownership, and problem-solving — not memorization.

Caveat:

Not everyone has public projects. Offer the chance to discuss anonymized work or a written project summary. Don’t penalize candidates without open-source contributions.

2. Ask Role-Relevant Technical Questions (No Trivia)

What to do:

Ask practical, role-specific questions:

Programming fundamentals (e.g., memory management, async flow)
SOLID principles or OOP concepts in context
Tech relevant to the role (e.g., Docker, message queues, testing frameworks)
Operating System concepts
Data Structures fundamentals (e.g., Big-O notation)

Bad:

“What’s the time complexity of a red-black tree insertion?”

Good:

“Let’s say you’re building an API for file uploads. How would you handle large files?”

Why it works:

You're checking if they can apply technical concepts to real problems.

Caveat:

Depth should match the role. Don’t quiz a frontend dev on database locking or a junior dev on system design at scale.

3. Code Review + Refactor: Test How They Think About Bad Code

What to do:

Provide a small, deliberately messy code sample — 2–3 files, 100–150 lines max. Include:

Unclear naming
Some logic duplication
Mild violations of style/architecture

Then ask them to:

Review the code and point out what’s wrong
Refactor it in a way they believe improves the design
Explain why their changes are better

Follow-up:

Ask: “What test would you write first after this refactor?” to assess how their cleanup impacts testability.

What you're testing:

Can they identify practical issues?
Do they understand real-world maintainability?
How do they prioritize: clarity, performance, structure?
Can they articulate technical decisions?

Why it works:

This simulates real work. Engineers constantly read and fix code, not just write from scratch. You see their eye for detail, tradeoffs, and communication ability.

Caveats:

Tailor to experience: Give simpler code to juniors (naming, formatting), more structural issues to seniors (e.g., poor separation of concerns).
Avoid trick questions: Make the code realistically bad — don’t set traps.
Timebox it: 30–45 minutes is enough. Don't let it sprawl.

4. Realistic Coding Task — AI Allowed

What to do:

Assign a real-world problem like:

Write a script in your preferred language that fetches data from a public REST API, processes it, and saves the output as a file (any format). Include at least 2 unit tests.

Rules:

They can use AI tools, docs, or the web — just like real life.
They must explain their code in detail.
Code must be clean, readable, and minimally documented.

What you're evaluating:

Can they code in the language they claim?
Do they understand the code they copied or referenced?
Do they value quality (tests, naming, structure)?

Why it works:

You’re not testing memory — you’re testing how they work in real-world scenarios, with real tools.

Caveat:

Be explicit: it's okay to use external help, but they must understand and own every line they submit.

Bonus: Soft Skills Appear Naturally

You don’t need a separate "culture fit" round. Communication and collaboration show up organically:

How they explain their project
How they justify a refactor
How they handle follow-up questions or critique

Just observe:

Are they clear?
Are they open to feedback?
Can they defend ideas without being defensive?

That’s culture.

Conclusion: A Better Interview Framework

A good interview doesn’t need whiteboards or brainteasers. It needs real-world simulation — code, discussion, reasoning, collaboration.

What you get:

Candidates who can actually do the job
A fairer process with less noise
Stronger signals in less time

Let’s stop playing games. Hire engineers like engineers.

02. Software Engineering Design & Security Principles

Syed Mohammad Ibrahim — Sun, 09 Mar 2025 09:14:51 +0000

This is the continuation of the course Secure Coding in Software Engineering.

Go to Home.
Go to previous chapter
Go to next chapter - TBD

Design Problems

Wicked Problem^[1]

A problem that can be clearly defined only by solving it or solving a part of it (Horst Rittel and Melvin Webber, 1973). You essentially solve the problem first to define the problem, then solve it again to find a solution that works.

"Design" is a wicked problem.

Source: https://xkcd.com/2021/

Software Design

Book Recommendation

Software Engineering Design by Carlos Otero 2012 https://a.co/d/0cXzdeok

Some concepts of software designs can be described as

Abstraction: Deals with creation of conceptual entities that facilitates solving the problem by focusing on the essential characteristics of the entities themselves (procedural and data abstraction). Required for good modularization (Liskov and Guttag 2010).
Modularization: Decomposition of the system until fine-grained components are created.
Encapsulation: Principles that deals with providing access to the services of the conceptual entities (modules, components etc.) by exposing only essential information and hiding details on how those services are carried out.
Coupling: The manner and degree of interdependence between software modules.
Cohesion: The manner and degree to which the tasks performed by a single software module are related to one another.
Separation of Interface and Implementation: While encapsulation deals with exposing and hiding implementation details, this principle of separation goes further and allows for an interface with the implementation (separate) to be swapped for modified or new behavior.
Completeness: Measures how well design units provide required services to achieve their intent.
Sufficiency: Measures how well design units provide services that are sufficient to achieve their intent.

Impact of Design Principles on Security

Abstraction and modularization help in being able to determine which of the modules are security relevant. If you don’t need a module, then it is redundant and should be removed.
For example, having a module to deal with users and their profile management can allow for security related functions for a user to be implemented easily.
Encapsulation and Interface-Implementation Separation can be used to achieve security goals for modules as well by checking security related functions as part of the design. This design principle also helps in reducing the number of surfaces that need to be checked or secured by separating the implementation from the interface.
For example, exposing administrative functionality for a web based application to authenticated and authorized users only where the authentication and authorization mechanisms are implemented independently of the Login.
Reducing coupling is a general software design goal and helps in securing modules because it also reduces the cascade of failures through the system.
For Example, NPM repository down: March 2016, a disgruntled developer unpublished a very popular package called left-pad due to a naming dispute that many other packages had as a dependency causing widespread disruption^[2].
Data abstraction is a key principle that has implications on privacy and securing data flows within an application.
The sufficiency principle similarly has implications on minimizing the surfaces that need to be secured.

Source: https://xkcd.com/2347/

NIST Special Publication 800-160, Volume 1 Revision 1

The following topics are taken from NIST Special Publication 800-160, Volume 1 Revision 1^[3],
Engineering Trustworthy Secure Systems:

How does software quality affect security?

There are several software quality metrics that can help assess the quality of the software and its design. High software quality can also lead to more secure software since it helps with the maintenance of software systems during its lifecycle.

Source: https://xkcd.com/1513/

For example, In a code base, a developer may state that a method/function is not going to be used by anyone and can stay in the code base. Even if no other components depend on it, it is more than likely:

That someone will reuse the code from the component
That someone will make it dependent on another software module
That an attacker will gain access to it

Finding bugs becomes easier when software quality is maintained!

Source: https://xkcd.com/1926/

Security Principles

Weakness

Mistakes or flaws (intentional or unintentional) in the software system that can lead to serious system level impacts.
You can use the CWE^TM language to describe such flaws.
Different from vulnerabilities, which involve using a weakness or set of weaknesses to achieve a desired effect or impact on the system.

Attack Surface

Informal Definition

We have heard the concept of a "surface" in principles of software system design – an interface to the interaction between modules.
An attack surface similarly provides attackers an interface to system resources that could be abused to access security vulnerabilities and to exploit the software system to achieve an attacker’s goals.

For a home, what are some example attack surfaces?

Formal Definition

Attacker can attack using channels (e.g., ports, sockets), invoke methods (e.g., API), and send data items (input strings or indirectly via persistent or stored data)
A system’s attack surface – Subset of the system’s resources (channels, methods, and data) that can be used in attacks on the system.
More attack surfaces likely means it is easier to exploit and cause more damage.

Source: Attack Surface Metric, Pratyusa K. Manadhata, CMU-CS-08-152, November 2008

Attack Vector

The set of inputs, actions and effects on the software system that when provided via the attack surface cause the exploitation of the system achieving the attacker/user’s goal.
Typically involves:
- Access to the software system
- Ability to manipulate input
- Ability and access to the configuration of the software environment

Illustration

Death Star, Star Wars

Source: Johnson, S. (1995). In Star Wars technical journal. Boxtree.

The reactor system at the core has a weakness that when it is hit with a blast, it causes a chain reaction that can be catastrophic. Intentionally hidden by Galen Erso, a scientist coerced to work for the Galactic Empire.
Exhaust port on the Death Star designed for exhaust (output) is an example of an attack surface.
The Death Star has a vulnerability where anything that can cause a chain reaction in the reactor core can lead to a catastrophic loss of the system.
The attack vector is the two proton torpedoes used to access the exhaust port, reach the reactor core and initiate the chain reaction.

Typical Security Objectives

Confidentiality: Information is only available to those who should have access.
Integrity: Data is known to be correct and trusted.
Availability: Information is available for use by legitimate users when it is needed.

Source: https://www.itgovernance.co.uk/blog/what-is-the-cia-triad-and-why-is-it-important

Other Security Objectives

Non-repudiation - Transactional security property where sender of a message is provided with proof of delivery and recipient of the message is provided with proof of sender’s identity. A real-life example of non-repudiation is when you sign for a package upon delivery—your signature serves as proof that you received it, preventing you from later denying acceptance.
Privacy - Property where all disclosure of information is provided only by authorized consent. A real-life example of privacy is when a doctor keeps your medical records confidential, ensuring that only authorized personnel can access them.
Audit/Accountability/Logging - Transactional security property where all security relevant actions and events are recorded and can be examined by authorized parties. A real-life example of audit/accountability/logging is security cameras in a retail store recording all transactions, allowing store managers to review footage if a theft or dispute occurs.
Id-entity - Typically digital identity, a security property that allows unique identification of individual entities allowing for authentication, authorization and access to services. A real-life example of identity is a passport, which serves as official proof of a person's identity and nationality when traveling internationally.

Set of Security Principles

A set of guiding principles for securing software systems need to be followed. The real "secret-sauce" behind most of the secure designs of software being followed in modern enterprises.

The following security principles already have existed since the 1970s and are from the following sources:

McGraw, Gary & Viega, John. "Keep It Simple." Software Development. CMP Media LLC, May, 2003.
Viega, John & McGraw, Gary. Building Secure Software: How to Avoid Security Problems the Right Way. Boston, MA: Addison-Wesley, 2002.
Saltzer, Jerome H. & Schroeder, Michael D. "The Protection of Information in Computer Systems" 1278-1308. Proceedings of the IEEE 63, 9 (September 1975).
Howard, Michael & LeBlanc, David. Writing Secure Code. 2nd. Redmond, WA: Microsoft Press, 2002.

Trustworthiness vs. Trust^[4]

"Trustworthiness implies that something is worthy of being trusted."
"Trust merely implies that you trust something, whether it is trustworthy or not." - Trust is a decision. - You should only trust things that have adequate evidence of being trustworthy.

Security Principle - Defence in Depth

Do not rely on a single security method.
Anticipate failures and layer basic security practices.
- Example: A Bank that manages money.
  - Security Guard
    
    Title: A private security officer at a Chinese factory in February 2004. Creator: Robbie Sproule. Source: Flickr. License: CC-By-2.0
  - Bank Building
    Title: Lloyds Bank Building. Creator: Pit-Yacker. Source: Wikimedia Commons. License: CC-By-2.5
  - Bank Teller
    Title: A teller in a branch of Bank Muamalat. Creator: Melwinsy. Source: Wikipedia. License: CC-By-SA-4.0
  - Bank Vault Title: Bank Vaults under Hotels in Toronto, Ontario. Creator: Jason Baker. Source: Flickr. License: CC-By-2.0
- The above example demonstrates that to get to the bank vault, one must pass through multiple steps of security to reach it.

Security Principle - Keep Security Simple

Keep security or protection mechanisms simple.
Makes it easy to understand, implement and analyze security.
- This has a direct co-relation to a CWE called CWE-655: Insufficient Psychological Acceptability.
Can also make it easy to use.

Security Principle - Attack Surface Reduction

Actively address and reduce any surfaces exposed to unauthenticated or unauthorized actors that allow for the system to be compromised against its security goals.
This can be done in a number of ways:
- From software design principles, the ideas of encapsulation or hiding functionality from entities (code, users, etc.) that don’t require it, separation of interface and implementation can also be used to control which entities have access to what functionality etc.
- In software systems, easiest way is to follow:
  - KISS principle: 'keep it simple stupid'. Keeping the system simple at design time tends to make it easy for actors to use the system and prevent misuse. It also helps in understanding and analyzing the system for attack surfaces and vulnerabilities.
  - Remove functionality that is not needed. The attack surface is essentially going to be all the code, functionality or data that is accessible by entities. Removing or reducing those can go a long way. Example could be keeping a code that we feel nobody is going to use, in the codebase which eventually someone ends up using bringing up weaknesses.

Security Principle - Establish Secure Defaults

The default configuration or state that ships with the software system should already include the most secure configuration. That means out of the box the software system should stop insecure actions.
Do not rely on an entity to configure the software system in order to enable security features or to make it run securely.
Example: A banking app requires strong passwords and enables two-factor authentication (2FA) by default, ensuring users have a secure account setup from the start.

Security Principle - Principle of Least Privilege

Not everyone needs access or privileges to do everything.
The actors (users, or programs) that use the software system should only be allowed to operate with the least privileges possible.
This limits the damage from an accident, error or attack.
Example: A hotel key card that only grants access to a guest’s room and common areas, but not to staff-only areas or other guests' rooms.

Security Principle - Fail Securely

Security controls in an application should assume the application is under attack by default.

Apple SSLVerifySignedServerKeyExchange checks validity of SSL certificate:

The second goto fail is not part of the if block:

if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
    goto fail;
    goto fail;
... other checks ...

fail:
    ... buffer frees (cleanups) ...
    return err;

Source: The Apple goto fail vulnerability: lessons learned, David A. Wheeler

Several issues here. But, one of them is the error code default was 0 which meant no error. This allowed attacker to skip other checks and return error of 0 as long as first statement returned no error. Here, failure cases should be checked explicitly and independently rather than stacking them one after another.^[5]

Security Principle - Complete Mediation ("Non-Passable")

Following from the earlier example, this principle involves making sure:
- To find all channels
- Check all inputs from untrusted sources
- Check as soon as possible and fail early
If the system has a client-server model, this means ensuring:
- Security checks are done on the server-side (client is not necessarily trusted, server may be trusted but not necessary)
- Check trustworthiness of environment (client or server) to ensure checks can also return trustworthy results
- Client-side checking can improve user-response and lower server load, however do client-side checks in addition to server-side checks.
Example: A credit card transaction where the bank verifies the card details and available balance every time a purchase is made, rather than relying on previously approved transactions. This ensures that all inputs are checked, trustworthiness is validated on the bank's secure server, and potential fraud is caught early.

Security Principle - Don't Trust Service Interface

This principle means the software system should not trust any of the interfaces it interacts with especially with regard to:
- Its behavior
- Its promises
The mere existence of an interface is not a contract that it will behave correctly.
Example interfaces:
- Third-party services and libraries
- Databases
- File systems
- Memory

Source: [6]

Security Principle - Separation of Duties/Privilege

This principle involves splitting the roles, duties and privileges that go along with those roles and duties into separate parts of the software system.
Example: You would not want a bank to allow the same customer to change the address of an account and authorize a check against an account.

Security Principle - Avoid Security Through Obscurity

This principle states:
- Avoid implementing obscure security mechanisms to "add" security.
- Adversaries and attackers likely already have access to the software system, source code and perhaps even the data for reverse engineering given enough resources.
- Relying on such mechanisms is very dangerous!
Assume the software system is already compromised and build security in.
Example: The gate here really does not really add any security nor does it add deterrence.

Security Principle - Avoid Non-Atomic Security Operations

This principles talks to how the software system should treat and implement security actions and operations atomically.
Example:
- Fake check scheme of the past.
- Both check verification and account balance update should be part of the same atomic transaction.
- Check needs to be verified and then the deposit updated as part of the same transaction.

Security Principle - Fix Security Issues Correctly

Security issues need to be treated at the root cause of the issue rather than just addressing symptoms.
The first gut response to an attack is to fix the issues responsible directly for the attack. You may only be addressing the symptoms of the problem.
However, this principle states that the software system and processes should be analyzed for a deeper analysis on what allowed the issue to happen in the first place.
As a software engineer you need to be able to fully understand the problem before you can design and implement a fix.

Security Principle - Least Common 'Security' Mechanism

This principle is actually a design principle where the system should be implemented in such a way as to reduce and minimize the use of shared mechanisms. For example, the use of /tmp or /var/tmp directories to store temporary files for users.
This applies to security mechanisms as well.
Shared objects provide potentially dangerous channels for information flow and unintended interactions.

What is wrong with this code?

public class ApplicationUser : IdentityUser<int, ApplicationUserLogin,ApplicationUserRole, ApplicationUserClaim>, User<int>
{
    public string Name { get; set; }
    public string Surname { get; set; }
    //code omitted for brevity
}

public class Student: ApplicationUser
{
    public int? Number { get; set; }

    [HttpPost]
    [ValidateAntiForgeryToken]
    public JsonResult Update([Bind(Exclude = null)] StudentViewModel model)
    {
        if (ModelState.IsValid)
        {
            ApplicationUser user = UserManager.FindById(model.Id);
            user = new Student
            {
                Name = model.Name,
                Surname = model.Surname,
                UserName = model.UserName,
                Email = model.Email,
                PhoneNumber = model.PhoneNumber,
                Number = model.Number, //custom property
                PasswordHash = checkUser.PasswordHash
            };
            UserManager.Update(user);
        }
    }
}

Source: [7]

Security Principle - Limit Resource Dependencies

This principle involves limiting the amount of resources depended upon by the software system wherever possible.
Fail2Ban – Limits excessive unauthorized login attempts over the network for an application based on logs and bans them when the limits are exceeded. Can be used for multiple applications including SSH.
Google, 2020 – Denial Of Service by UDP amplification attack^[8]:
- "In 2017, our Security Reliability Engineering team measured a record-breaking UDP amplification attack sourced out of several Chinese ISPs (ASNs 4134, 4837, 58453, and 9394), which remains the largest bandwidth attack of which we are aware."
- "The attacker used several networks to spoof 167 Mpps (millions of packets per second) to 180,000 exposed CLDAP, DNS, and SMTP servers, which would then send large responses to us. This demonstrates the volumes a well-resourced attacker can achieve. This was four times larger than the record-breaking 623 Gbps attack from the Mirai botnet a year earlier." - Damien Menscher, Security Reliability Engineer at Google

Security Principle - Ease Of Use For The Software System

This principle follows the previously discussed KISS principle.

However, as applied to security, the software system's human interface must be designed for ease of use so users will routinely and automatically use the protection mechanisms correctly.
Making it easy for users to secure their data and the software system, will make the system more secure.
Mistakes are reduced when security mechanisms in the software system closely match the user’s perception of their own protection goals. - Credit: Dr. David A. Wheeler

Security Principle - Hardening The Software System Environment

The software system is designed to run in an environment.

Building an application securely + deploying it in an insecure environment ≠ Secure Software System
The software system should also not assume anything about the environment wherever possible.

Types of Security Problems

We will discuss some type of security problems that are worth mentioning outside of the security principles.

The "Confused" deputy problem

A more privileged program ("a deputy") that is tricked by a lower privileged program into transitively giving it authority and misusing the authority. This is a type of privilege escalation.

Confused Deputy Example (Mainframe Billing System)

In an old mainframe billing system, a privileged billing process is responsible for generating and finalizing invoices. However, due to weak access controls, a user (or another less-privileged process) can trick the billing system into overwriting a bill—either by abusing its elevated permissions or by injecting unauthorized inputs.

Why is this a Confused Deputy Problem?

The billing system (deputy) has the authority to modify bills.
A user or process (attacker) without direct billing privileges tricks the system into writing incorrect values.
The billing system, acting on behalf of the user, unknowingly misuses its higher privilege, allowing unauthorized bill modifications.

A more modern analogy is Cloud Storage Misuse—where a web application (acting as a deputy) has write access to a cloud storage bucket. If a user uploads a malicious file, and the app inadvertently writes it with admin privileges, it allows unauthorized file modifications, similar to the mainframe billing issue.

Time-of-check-Time-of-Use (TOCTOU) problem

A race condition where a program checks the state of a part of the system (like a security credential) and the use of the results of that check.

Example: The setuid program bug^[9]. The following code had the race condition:
```
if (access("file", W_OK) != 0) {
    exit(1);
}

fd = open("file", O_WRONLY);
write(fd, buffer, sizeof(buffer));
```
Where, After the access check, before the open, the attacker replaces file with a symlink to the Unix password file /etc/passwd:
```
symlink("/etc/passwd", "file");
```

Covert/Side Channels

Surreptitious ways to send or "leak" data across data boundaries.
This requires some sort of access, coordination and/or sharing.

Impacts from Security Principle Violations

Information leakage: Sensitive or Unauthorized information got exposed.
Modification of data: Sensitive data was modified or unauthorized changes made to data.
Denial of Service:
- Unreliable Execution: The software system became unreliable or went into a degraded mode of operation.
- Resource Consumption: The software system ran out of resources.
Unauthorized code or command execution: Unauthorized code or commands were able to be run or executed by external users.
Escalation of privilege / Assumption of Identity: Malicious actors were able to hijack the identity of a privileged user or escalate their privileges within the software system or its environment.
Bypass Protection Mechanism: Any protection mechanisms were easily bypassed or circumvented.
Hide Activities: Activities performed on the software system or its environment were hidden from auditors or system evaluators or monitors.
Loss of trust: Users lost trust in the system they were using.

References

Wicked Problem - Wikipedia
npm left-pad incident
Ron Ross, Michael McEvilley, Maichael McEvilley. Engineering of Trustworthy Secure Systems. Vol 1 Rev 1. https://doi.org/10.6028/NIST.SP.800-160v1r1.
Definitions from "Principled Assuredly Trustworthy Composable Architectures" by Peter Neumann, 2004
Failing Securely
Is there any real-world “science” behind R2-D2’s computer interfacing arm?
How to save new record with hashed password in my custom table instead of aspnet user?
Five Most Famous DDoS Attacks and Then Some
Time-of-check to time-of-use

01. Introduction

Syed Mohammad Ibrahim — Sun, 09 Mar 2025 09:14:35 +0000

This is the continuation of the course Secure Coding in Software Engineering.

Go to Home.
Go to next chapter.

Almost every gadget around us uses software to operate, whether it be a hearing aid or an MRI machine. Software plays a major role in making every gadget operational and useful for its respective task. A lot of resources go into making the software work. But not enough attention is given to the software being safe, secure, behaving correctly, effects on other parts of the system(s). Yet, still somehow software still works.

Some of the reasons for the software being insecure

Poor communications (between all parties involved)
Commercial pressures
Poor system design
Poorly defined system requirements
Inaccurate estimates of required resources
Unmanaged Risks
Sloppy Development Practices
Use of immature technologies
Stakeholder politics

and many more... ^[1]

Importance of Secure Software Systems

What are the repurcussions of an insecure software or a software failure?

While it might not seem like a big deal, software failures can have serious consequences. Here are some events that illustrate this:

Injury & Loss of Life ^[2]
Loss of financial assets ^[1]
Loss of resources: organizational assets ^[3], the organization itself ^[1].
Loss of the software system: Denial of service
Loss of valuable or sensitive information
Loss of trust^*

^*The trust factor is not measurable but has a direct impact on the application usage.

And if the bugs were not enough, there are active adversaries trying to exploit vulnerabilities in software systems. These adversaries are:

Well-organized, similar to small businesses
Well-resourced, ranging from organized crime to nation states
Sophisticated in their technical abilities and attack methods

Source: The Different Types of Hackers and Their Motivations: An Overview

How do we identify the risks?

To identify the risks, one must look at the attacks.

Mitigations for Insecure Software

There are ways in which a couple of reasons for software being insecure mentioned above can be mitigated.

Poor System Design
- Giving a thought to security during the system design.
Unmanaged Risks
- Identifying security risks beforehand.
Sloppy Development Practices Certain measures can be put in place to prevent such practices, including but not limited to:
- Software Development Guidelines
- Software Lifecycle Management
- Code Review Process

What about using crypto, or anti-virus, or any other kind of Security Features?

"Security Features" are not the answer. Just by using Anti-virus, Crypto, Implementing your own Cryptographic Algorithm, using Open Source Software, or any other kind of Security Software is not going to provide you with a solution.

Furthermore, security through obsecurity is also not the answer to the problem. Like adding barriers is not going to stop a user from finding other ways to bypass the system, thus, making it more insecure (CWE-655). The situation can develop a loss of trust within the user and the software system.

Source: https://youtu.be/pqyFG-G4hF8?si=lt4FKxSA1dROA1J4

There is a trade-off between Security and usability/convenience. Interestingly, new ways are being explored to find a balance in usable security.

Measuring Security

There are a lot of places where one can retrieve information around the vulnerabilities. These location contain an extensive and actively updated information around the defects within the code.

CISA Cybersecurity Advisory, https://www.cisa.gov/news-events/cybersecurity-advisories
Debian Security Tracker, https://security-tracker.debian.org/tracker/
National Vulnerabilities Database/CVE, https://nvd.nist.gov/general/nvd-dashboard
MITRE CVE Database, https://cve.mitre.org/

Common Weakness Enumeration (CWE)

The common weaknesses enumeration defines common weaknesses in software that have security implications. This is a language that communicates the root cause of the vulnerability.

Difference from vulnerabilities:

Weaknesses can be thought of as mistakes or flaws (intentional or unintentional) in the software that can have serious system level impacts.
Vulnerabilities allow adversaries to take advantage of accessible weaknesses that are exploitable in order to achieve their attack goals.

For example, when a vulnerability says that it is a buffer-overflow, that sentence in itself is useful only to a certain extent. Was it a out of bounds read/write? CWE can be attached to the vulnerability that will help in explaining why the vulnerability occurred. Try looking up CWE-125 or CWE-787 for more details.

What about Cross-Site Scripting (XSS)? Is it an attack or a weakness?

The XSS is an attack, at heart of which lies a weakness termed Improper Neutralization of Input During Web Page Generation (CWE-79).

Similarly, SQL Injection is an attack which is caused by Improper Neutralization of Special Elements used in an SQL Command (CWE-89).

While going through a CWE, you will see a section covering consequences. The heading in the page is Common Consequences and they describe the impact on the application if the weakness is not fixed. However, not all the technical impact will be accurate to the application being addressed. It is upto the security personnel to educate the developer, what will happen if the weakness is not addressed.

Weakness Inception within Software

The following diagram shows the different layers of software over the operating system.

The weakness can exist anywhere along these layers. The criticality of the weakness increases from top to bottom. If there is a weakness within the Hardware, then it is extremely difficult to mitigate it as upgrading hardware is not easy. In contrast, upgrading an application is much easier due to the availability of internet and in-place upgrade mechanisms within the software. As a software developer, one has to think about all the aspects of each layer while writing a software.

Source: https://upload.wikimedia.org/wikipedia/commons/thumb/e/e2/Waterfall_model.svg/1600px-Waterfall_model.svg.png

Each level of the software model incurs a security review. For example, in requirements phase, having a documentation is a step. However, if the documentation for some reason is incomplete/inconsistent, then it is a security risk (CWE-1112, CWE-1059, and more.). The security impact is indirect in this case as issues with documentations are primarily quality focused. This doesn't mean that one should never write any documentation, rather address the important or critical aspects of the application being developed.

A majority of the weaknesses are found in the implementation phase, but they can be traced back to the requirements phase.

Is it possible to write secure code at all?

The answer is Yes. Developers don't share how one can write secure code due to various reasons, some of them being, insufficient understanding of the concepts, company restrictions, insufficient documentation (except in their minds), etc. CWE can help with that. It is designed to assist the developer in writing secure code and sharing it with their peers and public.

One thing to note is what the CWE doesn't do is observing the human processes like in an organization or processes like for example, if the company doesn't have a security policy, there is no mapping within CWE to address it.

Secure Development Lifecycle

An organization level of security risk can be addressed by following a secure development lifecycle. It encapsulates a software model with security findings. Some examples of Secure Development Models are:

Building Security In Maturity Model (BSIMM) - https://www.synopsys.com/software-integrity/software-security-services/bsimm-maturity-model.html
Software Assurance Maturity Model (SAMM) - https://owaspsamm.org/
Microsoft Security Development Lifecycle (SDL) - https://www.microsoft.com/en-us/securityengineering/sdl

To pick one, Microsoft has built the SDL for internal use and have provided information publicly to everyone on how to proceed in different stages:

Source: https://learn.microsoft.com/en-us/archive/technet-wiki/t/resources/5554.sdl_5f00_steps.jpg

Governance and Education Phase - Security Training

Training the developers is the key, especially in secure coding practices. A training should be focused on:

Secure Design
Threat Modeling
Secure Coding
Security Testing
Privacy analysis
Policy and Governance guidelines

Requirements Phase

This phase is used to establish the security requirements of the entire software system. A Security Risk Assessment^[4] and a Privacy Risk Assessment^[5] can help to identify which functions of the software need to be closely looked at.

For example, if the software stores personal information, the functionality of the software that governs stores, transmission and uses should be examined closely and requirements such as
HIPAA rules should be applied to determine what security requirements should be put in place.

What is the minimum criteria that must be met in order to pass the quality or security of the software system for a release?

For example, no vulnerabilities marked critical should be present in the release.

Once the minimum criteria is set, it should not be relaxed or compromised. Getting this agreement ahead of time from stakeholders can help establish the criteria.

Design Phase

With the security requirements in hand, the design phase can proceed accounting for those additional security requirements. The design requirements outline the plan for the project to follow through the rest of the phases.

The security requirements should not be thought of as an add-on. The security requirements should be "baked-in" to the design of the software system. Especially with cryptographic functionality, the design requirements should account for what, how and why the minimum cryptographic requirements should be used.

Attack Surface analysis/reduction and Threat modeling is generally performed during this phase.

Implementation Phase

The implementation phase of the security development lifecycle is focused on how the software system is planned to be developed, deployed and used. This includes all the documentation and tools geared towards the goal above.

This phase generally involves identifying and using only an approved list of tools, security checks etc. It also involves deprecating unsafe functions of the software system and performing static code analysis.

Verification Phase

The verification phase acts as the phase where you are able to check and verify whether the security requirements were really met in the implementation. A public release security and privacy review can be performed during this phase. This may also include any consultations with institutional review boards.

Dynamic Analysis techniques are used to test the software system as it runs. Fuzz Testing techniques are also used to ensure no failures due to random input result.

An attack surface review is performed to ensure any and all attack vectors have been addressed as a result of any changes in the previous phases.

Operations Phase - Release and Incident Response

I am just a coder... Who cares after the code is releases? #amiright

This is a critical part of the lifecycle.

The Release phase is used to ready the software system for consumption by customers. A final security and privacy review is performed. Licensing of the software and its terms and any servicing terms for third-party software are put in place. Release archiving is performed storing all source code, documentation, specifications, design (including security) documents are archived.

An incident response plan is put in place including any Emergency response plans for the software system.

Detailed description of each step is available at Microsoft's SDL^[6].

References

The references are provided as URLs, however, if the original content is for some reason not accessible then the information is recorded as a copy of the original content under docs/references.

Why software fails? (2005) by Robert N. Charette
Medical Devices: The Therac-25^* by Nancy Leveson
Analyzing Software Failure on the NASA Mars Climate Orbiter (2017) by Christopher Demicoli
What is Security Risk Assessment and How does it work? by Synopsys
What is Data Privacy Risk Assessment and Why is it Important? by Privacy Pillar
The Security Development Lifecycle by Microsoft

Secure Coding in Software Engineering

Syed Mohammad Ibrahim — Sun, 09 Mar 2025 09:14:07 +0000

Welcome to Secure Coding in Software Engineering, a comprehensive course designed to equip you with essential knowledge and skills in securing software systems. In today's interconnected world, where software vulnerabilities pose significant risks to organizations and individuals, understanding software security principles is paramount. This course is crafted to provide you with a solid foundation in software security concepts, methodologies, and best practices.

Acknowledgement

I would like to thank Prof. Gananand Kini for his efforts and contributions in creating the original course from which this course is derived from. List of sources from where the course derived from:

Prof. Gananand Kini's coursework.
Title: Secure Software Design and Programming: Class Materials
- Author: Prof. David A. Wheeler
- Source: https://dwheeler.com/secure-class/index.html
- License: CC BY-SA 3.0
Title: Introduction to Secure Coding
- Author: Andrew Buttner and Larry Shields
- Source: https://opensecuritytraining.info/IntroSecureCoding.html
- License: CC BY-SA 3.0

Learning Objectives

Throughout this course, you will achieve the following learning objectives:

1. Understanding the Secure Development Lifecycle (SDLC)

Define and apply the principles of the Secure Development Lifecycle (SDLC).
Learn how to effectively communicate and mitigate software security weaknesses within the SDLC framework.

2. Penetration Testing and Security Analysis

Apply penetration testing techniques to evaluate software security.
Utilize security analysis techniques and tools to assess software security posture.

3. Identification and Remediation of Software Weaknesses

Develop the ability to explain weaknesses in software systems.
Apply defenses to remediate software exploits and vulnerabilities.

Note
This course will not cover topics such as anti-virus technology, hacking, or advanced exploitations. While relevant aspects of software design and architecture may be highlighted, they are not the primary focus.

What You Will Gain

By completing this course, you will acquire practical skills and knowledge to:

Audit software systems and identify security weaknesses effectively.
Describe identified weaknesses using MITRE's CWE^TM.
Master methodologies, techniques, and tools used in secure code review processes.
Identify and address security weaknesses efficiently.
Conduct secure code reviews for various purposes, including enhancing code quality, improving communication, and educating others.

Why Take This Course?

Many security education programs predominantly focus on exploiting vulnerabilities to showcase weaknesses. In contrast, this course emphasizes proactive measures to secure software systems through best practices. It fills the gap in traditional software engineering classes, which often overlook security aspects. While there's a gradual shift in academic curriculums, this course provides you with practical knowledge and skills essential for securing software systems in today's digital landscape.

INFO
The course will use the CWE-699 as base view which is focused on the security of a software. There are other views, which can be explored here but are not within the scope of this course.

Course Structure

This course is structured into multiple chapters, each covering different areas and topics within software development and security. Throughout the course, relevant code references will be provided in various programming languages such as C#, Python, etc., although the concepts discussed are applicable to any modern-day programming language. There will be references to relevant excerpts and images and reading material will be provided as references as and when required.

Understanding Vulnerabilities

To comprehend vulnerabilities within software systems, the course will employ a root cause analysis (RCA) approach, aided by Common Weakness Enumerations (CWE).

Core Concepts

The course will begin by exploring fundamental concepts essential for secure software development, including:

Tenets of Software System Design.
Security Principles and the Secure Software Development Cycle.

In-Depth Exploration

In addition to the core concepts, the course will delve into the following areas in-depth:

Input Security
Cryptography
Authentication & Authorization
Session Management
Error Handling
Logging
Debug Code
Performing Secure Code Reviews.

License

The course is licensed under Creative Commons "Share Alike" license. https://creativecommons.org/licenses/by-sa/3.0/

The course is derived from Introduction to Secure Software Engineering class by Gananand Kini et al.

Check the LICENSE for more details.

Contribute

Use the github issues section to know more.

Credentials substitution at runtime in Python

Syed Mohammad Ibrahim — Sat, 01 Apr 2023 23:14:24 +0000

Introduction

Often we hear that credentials should not be hardcoded in the code or Version Control (like git). You can leverage the dynamic substitution of such credentials using Environment variables tied to the code as a variable.

Pre-requisite

Python 3.8 or up
PyYaml - To read YAML configuration file

Steps

Create a yaml file as the following

# credentials.yml

aws:
  access_key_id: "${AWS_ACCESS_KEY_ID}"
  secret_access_key: "${AWS_SECRET_ACCESS_KEY}"

We will read this yaml file and get the python dictionary object

# main.py
from typing import Dict
import yaml

def read_credentials_file() -> Dict:
  try:
    with open("credentials.yml", mode="r", encoding="utf-8") as cred_file:
      return yaml.safe_load(cred_file)
  except yaml.YAMLError as yaml_err:
    print(f"Unable to read the file. Error: {yaml_err}")
    raise

We will use the string.Template from the standard library to substitute the value from the environment variables

# main.py
import string
import os

def substitute_creds(creds: Dict) -> None:
  creds["aws"]["access_key_id"] = string.Template(
    creds["aws"]["access_key_id"]
  ).substitute(
    {"AWS_ACCESS_KEY_ID": os.getenv("AWS_ACCESS_KEY_ID")}
  )

  creds["aws"]["secret_access_key"] = string.Template(
    creds["aws"]["secret_access_key"]
  ).substitute(
    {"AWS_SECRET_ACCESS_KEY": os.getenv("AWS_SECRET_ACCESS_KEY")}
  )

Add the following two variables as part of the environment. They can be added in the .env file as well

$ export AWS_ACCESS_KEY_ID="abcd1234"
$ export AWS_SECRET_ACCESS_KEY="secret123"

Complete Program

# main.py
from typing import Dict
import string
import yaml
import os

def read_credentials_file() -> Dict:
  try:
    with open("credentials.yml", mode="r", encoding="utf-8") as cred_file:
      return yaml.safe_load(cred_file)
  except yaml.YAMLError as yaml_err:
    print(f"Unable to read the file. Error: {yaml_err}")
    raise

def substitute_creds(creds: Dict) -> None:
  creds["aws"]["access_key_id"] = string.Template(
    creds["aws"]["access_key_id"]
  ).substitute(
    {"AWS_ACCESS_KEY_ID": os.getenv("AWS_ACCESS_KEY_ID")}
  )

  creds["aws"]["secret_access_key"] = string.Template(
    creds["aws"]["secret_access_key"]
  ).substitute(
    {"AWS_SECRET_ACCESS_KEY": os.getenv("AWS_SECRET_ACCESS_KEY")}
  )

if __name__ == "__main__":
  credentials = read_credentials_file()
  substitute_creds(credentials)

  # WARNING: Never print or log credentials or any sensitive information
  print(f"Credentials: {credentials}")

The above code when run should produce the following output

$ python3 main.py
Credentials: {"aws": {"access_key_id": "abcd1234", "secret_access_key": "secret123"}}

How to handle different application environments like Prod, Dev, Test, etc.?

Syed Mohammad Ibrahim — Sat, 01 Apr 2023 17:34:12 +0000

Introduction

There are times when we are in a dilemma as to how to properly use application environments. It gets confusing really fast. I will try to explain the approach (that I see) makes sense.

I will be using Python in this blog, but this implementation is agnostic of the programming language.

Pre-requisites

Python 3.8.x or higher
PyYaml library - To read our YAML configuration files

Lets get started!

Create a yaml file just like below

# settings.yml
default: &default
  api_url: "https://example.com/dev"
  aws: &aws
    s3_bucket:
      - my-bucket

dev: &dev
  <<: *default

test: &test
  <<: *default
  api_url: "https://example.com/test"

prod: &prod
  <<: *default
  api_url: "https://prod.example.com/"
  aws:
    <<: *aws
    s3_bucket:
      - my-prod-bucket

In the above yaml, we are using the inheritance to override the configurations for individual environments.

To pass the correct configuration, we can leverage argparse which parses command-line arguments for us. The following python script does that.

# main.py
import argparse

def read_cli_arguments():
  arg_parser = argparse.ArgumentParser()
  arg_parser.add_argument(
        "--app-env",
        required=True,
        action="store",
        choices=("prod", "dev", "test"),
        help="Application environment to run in"
    )
  return arg_parser.parse_args()

Next, we read the configuration file based on the environment

# main.py
from typing import Dict
import yaml

def read_settings(app_env: str) -> Dict:
  try:
    with open("settings.yml", mode="r", encoding="utf-8") as config:
      configs: Dict = yaml.safe_load(config)
  except yaml.YAMLError as yaml_err:
    print(f"Error occurred while reading the file. Error: {yaml_err}")
    raise
  return configs[app_env]

Reading the configuration dictionary is now as easy as

# main.py

settings_prod: Dict = read_settings("prod")
print(f"Prod Configurations: {settings_prod}")

settings_test: Dict = read_settings("test")
print(f"Test Configurations: {settings_test}")

Finally, we use this as part of running our main.py file from the command-line like this

$ ls
main.py     settings.yml

$ python3 main.py --app-env prod

Complete Code

# main.py
from typing import Dict
import argparse
import yaml

def read_cli_arguments():
  arg_parser = argparse.ArgumentParser()
  arg_parser.add_argument(
        "--app-env",
        required=True,
        action="store",
        choices=("prod", "dev", "test"),
        help="Application environment to run in"
    )
  return arg_parser.parse_args()

def read_settings(app_env: str) -> Dict:
  try:
    with open("settings.yml", mode="r", encoding="utf-8") as config:
      configs: Dict = yaml.safe_load(config)
  except yaml.YAMLError as yaml_err:
    print(f"Error occurred while reading the file. Error: {yaml_err}")
    raise
  return configs[app_env]


# Program Execution Starts Here
if __name__ == "__main__":
  # Read CLI arguments
  args = read_cli_arguments()

  # Retrieve specific configurations
  settings: Dict = read_settings(app_env=args.app_env)

  print(f"Configs: {settings}")

Executing the above code on the terminal

$ python3 main.py --app-env prod
Configs: {"api_url": "https://prod.example.com/", "aws": {"s3_bucket": ["my-prod-bucket"]}}

Cheers!

Add coverage report with pytest and Gitlab CI

Syed Mohammad Ibrahim — Thu, 16 Mar 2023 14:49:36 +0000

Introduction

In this blog, I am going to cover the integration of Pytest with Poetry and then using the coverage to generate a report that is displayed as part of Gitlab file diffs.

I will be using poetry to install and manage my dependencies.

Pre-requisite

Python 3.8.x or higher
Poetry 1.4
Pytest 7.2.x
Coverage 7.2.1
An empty Gitlab project/repository with the name gitlab-demo-project

Setting up the project

This part assumes that you have Python and Poetry installed and setup in your development environment. Additionally, you have cloned the empty project in your local. All the following instructions are to be done in the root of the cloned project.

Initialize the current project with poetry using ```bash

poetry init

Follow the on-screen instructions that will allow you to add some necessary information and generate a `pyproject.toml` file to contain your dependency. Your project structure should look something like this
```bash


.
├── README.md
├── pyproject.toml
├── gitlab_demo_project
│   └── __init__.py
└── tests
    └── __init__.py

Install pytest and coverage using poetry under a test group ```bash

poetry install pytest --group test

```bash


poetry install coverage --group test

In the pyproject.toml file, add the following lines which are responsible for pytest and coverage configurations while running. ```toml

[tool.pytest.ini_options]
testpaths = ["tests"]
addopts = "-s -v --durations=0"
cache_dir = ".cache/pytest_cache"

[tool.coverage.run]
branch = true
source = ["gitlab-demo-project"]
command_line = "-m pytest"

[tool.coverage.report]
show_missing = true

[tool.coverage.xml]
output = "coverage.xml"


4. Create a file called `.gitlab-ci.yml` in the root of the project and copy the following contents in it
```yaml


default:
  image: python:3.8

stages:
  - test

variables:
  PIP_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pip"
  POETRY_CACHE_DIR: "$CI_PROJECT_DIR/.cache/pypoetry"
  POETRY_VIRTUALENVS_IN_PROJECT: "true"

cache:
  paths:
    - .cache/pip
    - .cache/pytest_cache
    - .cache/pypoetry
    - .venv

# Install specific version of poetry using pipx
# Poetry installation is recommended through pipx
# https://python-poetry.org/docs/#ci-recommendations
.poetry_setup: &poetry_setup
  before_script:
    - python -V
    - python -m pip install --upgrade pip
    - python -m pip install pipx
    - python -m pipx install poetry==1.4.0
    - export PATH=$PATH:$HOME/.local/bin
    - poetry install

Testing:
  <<: *poetry_setup
  stage: test
  script:
    - poetry run coverage run
    - poetry run coverage report
    - poetry run coverage xml
  coverage: '/TOTAL.*\s+(\d+%)$/'
  artifacts:
    # https://docs.gitlab.com/ee/ci/yaml/index.html#artifactsexpire_in
    expire_in: 1 week

    # https://docs.gitlab.com/ee/ci/testing/test_coverage_visualization.html
    reports:
      coverage_report:
        coverage_format: cobertura
        path: coverage.xml

Create a file in your gitlab_demo_project folder called hello.py and add the following lines in it ```python

def call_hello():
print("hey, its me!")


6. Create a file in your `tests` folder called `test_hello.py` and add the following lines in it
```python


from gitlab_demo_project.hello import call_hello

def test_hello():
    assert call_hello() == "hey, its me!"

Verify the test case using pytest tests/ command on the terminal.

Checkout a branch using the git bash named testing-gitlab-coverage and commit all the changes in that branch.
Once committed, push all the changes to remote and create a merge request. The pipeline should be triggered with the name Testing. After it succeeds, check the diff of files in the merge request. It should have the following lines appearing

References

1: Pytest command-line flags https://docs.pytest.org/en/7.2.x/reference/reference.html#command-line-flags
2: Coverage configurations https://coverage.readthedocs.io/en/7.2.1/config.html
3: Gitlab Artifacts https://docs.gitlab.com/15.9/ee/ci/yaml/
4: Gitlab Artifacts Report https://docs.gitlab.com/15.9/ee/ci/yaml/artifacts_reports.html
5: Gitlab Test Coverage visualization image https://docs.gitlab.com/ee/ci/testing/img/test_coverage_visualization_v12_9.png

Mocking AWS Dynamo Db calls during testing

Syed Mohammad Ibrahim — Sun, 24 Apr 2022 03:16:24 +0000

Introduction

It is always a good idea to write test cases for your application when you build any new feature or the application from scratch itself. Testing allows your code to be more bug free and gives a clear sense of where the development should go and if there are any bottlenecks involved.

In this space, I am going to go over the basics of how to mock AWS Dynamo DB calls in while testing in Python. I will be using the moto library to do that.

Setup

I will be using Python version 3.9.x for the demonstration and following additional libraries:

pytest - version 7.1.1
moto - version 3.1.5
boto3 - version 1.21.45

I will be using virtualenv to manage my packages, but you are open to use whatever seems appropriate.

To install these libraries, use the following commands on your terminal or command prompt:

pip install pytest==7.1.1.

Installs pytest version 7.1.1

pip install moto[all]==3.1.5

Installs moto version 3.1.5 with all of it's dependencies. The moto library can mock a lot of AWS services. For installing all of it's dependencies - which it doesn't install by default - we need to add the [all] part while installing it.

pip install boto3==1.21.45

Installs boto3 version 1.21.45

You can check out the complete list of requirements for this project on my GitHub page.

Project Structure

The project structure for this demo is going to look like this

MockDynamoDbExample
├── __init__.py
├── src
│   ├── __init__.py
│   └── service.py
└── test
    ├── __init__.py
    └── test_service.py

Implementation

Let's start implementing the mocks.

First, create a base folder (in my case, it is MockDynamoDbExample). Then create two sub-folders src and test. As the name suggest, src will contain the code which needs to be tested and test will contain our tests to the given source code.

Next, we need a running service that will more or less reflect the operations we want to perform in the real world. Create empty __init__.py and service.py files in the src folder. The __init__.py is created so that the current folder is treated as a module. We are not going to edit that file. By just existing, the file indicates to the Python Interpreter that the current folder is a module. The service.py file is where we are going to write the source code that requires testing.

Let's start by writing all the imports and the constructor method

from boto3.dynamodb.conditions import Key
import boto3


class Service:
    __dynamodb = None
    __table = None

    def __init__(self, table_name: str, env="dev") -> None:
        """
        Initiates an object of this class

        :param table_name: The table this service is going to perform CRUD operations for.
        :param env: The environment context the application is running in.
        """

        # Create a boto3 resource for local instance of dynamodb
        resource = {"region_name": "us-east-2"}
        if env == "dev":
            resource["endpoint_url"] = "http://localhost:8000"
        self.__dynamodb = boto3.resource("dynamodb", **resource)

        # Get the table
        self.__get_table(table_name)

The gist of the code in the constructor method is that it creates a boto3.resource instance depending on the env value passed. During testing, we won't be deploying an instance of Dynamo Db, that's why I had put an env check. You are free to play around with it.

Let's implement the __get_table method which is responsible for either getting us the table, if it exists or create a new one. Copy the below code in the same class

def __get_table(self, table_name: str):
    # Get the table from the dynamodb instance
    self.__table = self.__dynamodb.Table(table_name)

    try:
        # Check whether the table exists or not
        self.__table.table_status
    except:
        # If the table doesn't exist, an exception will be thrown.
        # Create the table if that happens.
        print("The table user doesn't exist. Creating now...")
        self.__create_table(table_name)

def __create_table(self, table_name: str):
    try:
        table = self.__dynamodb.create_table(
            TableName=table_name,
            KeySchema=[
                {"AttributeName": "username", "KeyType": "HASH"},
                {"AttributeName": "age", "KeyType": "RANGE"},
            ],
            AttributeDefinitions=[
                {
                    "AttributeName": "username",
                    "AttributeType": "S",
                },
                {
                    "AttributeName": "age",
                    "AttributeType": "N",
                },
            ],
            ProvisionedThroughput={
                "ReadCapacityUnits": 1,
                "WriteCapacityUnits": 1,
            },
        )

        # Wait until the table exits
        table.wait_until_exists()
    except Exception:
        raise Exception(f"Unable to create the table {table_name}")

    # Set the instance variable to the new table created
    self.__table = table

def delete_table(self):
    self.__table.delete()

To give an overview, our table contains a primary-key username which is of key type HASH and age as a key type of RANGE. I am using the create_table method that is provided as part of the boto3.resource instance to create the desired table. The upstream code, namely __get_table method is responsible for checking whether the table exists in the first place or not. If it does, we return early with it's instance.

Now, we implement all the CRUD operations that are required to perform the task for the database.

def create_user(self, username: str, email: str, age: int, first_name: str, last_name: str):
    user_obj = {
        "username": username,
        "email": email,
        "age": age,
        "first_name": first_name,
        "last_name": last_name
    }

    # Insert the data into table
    self.__table.put_item(Item=user_obj)

def get_user_by_username(self, username: str):
    response = self.__table.query(
        KeyConditionExpression=Key("username").eq(username)
    )
    items = response["Items"]

    # Return none, if the length of the items list is not 1
    if len(items) != 1:
        return None

    # Return the value fetched from the database
    return items[0]

def delete_user_by_username(self, username: str):
    response = self.__table.delete_item(
        Key={"username": username}
    )

    return response

The above CRUD operations can vary depending on your use case. For the purpose of this blog, I will be using these basic operations. You can implement your own CRUD operations by following this link.

The complete service.py file should look like

from boto3.dynamodb.conditions import Key
import boto3


class Service:
    __dynamodb = None
    __table = None

    def __init__(self, table_name: str, env="dev") -> None:
        """
        Initiates an object of this class

        :param table_name: The table this service is going to perform CRUD operations for.
        :param env: The environment context the application is running in.
        """

        # Create a boto3 resource for local instance of dynamodb
        resource = {"region_name": "us-east-2"}
        if env == "dev":
            resource["endpoint_url"] = "http://localhost:8000"
        self.__dynamodb = boto3.resource("dynamodb", **resource)

        # Get the table
        self.__get_table(table_name)

    def __get_table(self, table_name: str):
        # Get the table from the dynamodb instance
        self.__table = self.__dynamodb.Table(table_name)

        try:
            # Check whether the table exists or not
            self.__table.table_status
        except:
            # If the table doesn't exist, an exception will be thrown.
            # Create the table if that happens.
            print("The table user doesn't exist. Creating now...")
            self.__create_table(table_name)

    def __create_table(self, table_name: str):
        try:
            table = self.__dynamodb.create_table(
                TableName=table_name,
                KeySchema=[
                    {"AttributeName": "username", "KeyType": "HASH"},
                    {"AttributeName": "age", "KeyType": "RANGE"},
                ],
                AttributeDefinitions=[
                    {
                        "AttributeName": "username",
                        "AttributeType": "S",
                    },
                    {
                        "AttributeName": "age",
                        "AttributeType": "N",
                    },
                ],
                ProvisionedThroughput={
                    "ReadCapacityUnits": 1,
                    "WriteCapacityUnits": 1,
                },
            )

            # Wait until the table exits
            table.wait_until_exists()
        except Exception:
            raise Exception(f"Unable to create the table {table_name}")

        # Set the instance variable to the new table created
        self.__table = table

    def delete_table(self):
        self.__table.delete()

    def create_user(self, username: str, email: str, age: int, first_name: str, last_name: str):
        user_obj = {
            "username": username,
            "email": email,
            "age": age,
            "first_name": first_name,
            "last_name": last_name
        }

        # Insert the data into table
        self.__table.put_item(Item=user_obj)

    def get_user_by_username(self, username: str):
        response = self.__table.query(
            KeyConditionExpression=Key("username").eq(username)
        )
        items = response["Items"]

        # Return none, if the length of the items list is not 1
        if len(items) != 1:
            return None

        # Return the value fetched from the database
        return items[0]

    def delete_user_by_username(self, username: str):
        response = self.__table.delete_item(
            Key={"username": username}
        )

        return response

Generally, I use double-underscore's in front of methods that will be used internally within a class and are not required outside of it. I feel this to be a good coding standard. However, you are open to use the way you feel like.

Testing

Moving to the testing of this service, create two files __init__.py and test_service.py files under the test directory. As with the src files, the __init__.py will be used for setting the current directory as module and will be empty. The test_service.py will be where our test code is going to be.

I am using a combination of pytest and unittest modules to perform testing.

Let's start by writing the setUp and tearDown methods. These methods are automatically whenever a test case is executed from the test suite.

from MockDynamoDbExample.src.service import Service
from moto import mock_dynamodb
from unittest import TestCase


@mock_dynamodb
class TestService(TestCase):
    def setUp(self) -> None:
        """Method called before every test case is executed"""

        # Create an instance of the Service class
        self.service = Service("user", env="test")

    def tearDown(self) -> None:
        """Method called after every test case has finished execution"""

        # Clear the table after use
        self.service.delete_table()

        # Reset the service variable
        self.service = None

I am importing few things here, like the Service class that we implemented, the mock_dynamodb decorator from the moto library and TestCase from the unittest module.

The mock_dynamodb is going to be helpful in mocking all of our Dynamo Db related calls. This import will be used as a decorator. To learn more about decorators in general, follow this link.

In the setUp method, we are creating a Service class instance with "user" as the table name and environment as "test". The tearDown method implements the cleanup functionality. Both of these methods are called before and after every test case respectively.

Moving on, the following code implements the first test case which tests for create_user method in services

def test_create_user(self):
    username = "test-mike"
    age = 19
    first_name = "Mike"
    last_name = "Ross"
    email = "test_mike@example.com"

    try:
        self.service.create_user(username, email, age, first_name, last_name)
    except Exception as exc:
        assert False, f"service.create_user raised an exception {exc}"
    assert True

We are testing the creation success using assert True at the end.

Let's run the test case by going over to the terminal or command prompt. Make sure that you are in the root directory of this project while executing the following command:

pytest test/test_service.py

It should print out the following on Linux system

(venv) ibi@ibi:~/MockDynamoDbExample$ pytest MockDynamoDbExample/test/test_service.py 
======================================================================================== test session starts =========================================================================================
platform linux -- Python 3.9.12, pytest-7.1.1, pluggy-1.0.0
rootdir: /home/ibi/MockDynamoDbExample
collected 1 items                                                                                                                                                                                    

MockDynamoDbExample/test/test_service.py ...                                                                                                                                                   [100%]

========================================================================================= 1 passed in 1.46s ==========================================================================================

For windows powershell, the output should look like

(venv) PS D:\MockDynamoDbExample> pytest test\test_service.py
================================================= test session starts =================================================
platform win32 -- Python 3.9.10, pytest-7.1.1, pluggy-1.0.0
rootdir: D:\MockDynamoDbExample
collected 1 items

test\test_service.py ...                                                                                         [100%]

================================================== 1 passed in 1.63s ==================================================

Adding another test case to test getting a user by username.

def test_get_user_by_username(self):
    username = "test-mike"
    age = 19
    first_name = "Mike"
    last_name = "Ross"
    email = "test_mike@example.com"

    # Create a user in the database
    try:
        self.service.create_user(username, email, age, first_name, last_name)
    except Exception as exc:
        assert False, f"service.create_user raised an exception {exc}"

    # Get the user by username from the database
    try:
        response = self.service.get_user_by_username(username)
    except Exception as exc:
        assert False, f"service.get_user_by_username raised an exception {exc}"

    # Verify the details
    assert response is not None
    assert response["username"] == username
    assert response["age"] == age
    assert response["email"] == email
    assert response["first_name"] == first_name
    assert response["last_name"] == last_name

In this test case, we are testing the insertion and fetch performed by Dynamo Db.

The complete file should look like

from MockDynamoDbExample.src.service import Service
from moto import mock_dynamodb
from unittest import TestCase


@mock_dynamodb
class TestService(TestCase):
    def setUp(self) -> None:
        """Method called before every test case is executed"""

        # Create an instance of the Service class
        self.service = Service("user", env="test")

    def tearDown(self) -> None:
        """Method called after every test case has finished execution"""

        # Clear the table after use
        self.service.delete_table()

        # Reset the service variable
        self.service = None

    def test_create_user(self):
        username = "test-mike"
        age = 19
        first_name = "Mike"
        last_name = "Ross"
        email = "test_mike@example.com"

        try:
            self.service.create_user(username, email, age, first_name, last_name)
        except Exception as exc:
            assert False, f"service.create_user raised an exception {exc}"
        assert True

    def test_get_user_by_username(self):
        username = "test-mike"
        age = 19
        first_name = "Mike"
        last_name = "Ross"
        email = "test_mike@example.com"

        # Create a user in the database
        try:
            self.service.create_user(username, email, age, first_name, last_name)
        except Exception as exc:
            assert False, f"service.create_user raised an exception {exc}"

        # Get the user by username from the database
        try:
            response = self.service.get_user_by_username(username)
        except Exception as exc:
            assert False, f"service.get_user_by_username raised an exception {exc}"

        # Verify the details
        assert response is not None
        assert response["username"] == username
        assert response["age"] == age
        assert response["email"] == email
        assert response["first_name"] == first_name
        assert response["last_name"] == last_name

Additionally, if you don't want to use a class based approach and would like to write independent functions then you can do the following

@mock_dynamodb
def test_create_user():
    service = Service("user", "test")
    username = "test-mike"
    age = 19
    first_name = "Mike"
    last_name = "Ross"
    email = "test_mike@example.com"

    try:
        service.create_user(username, email, age, first_name, last_name)
    except Exception as exc:
        assert False, f"service.create_user raised an exception {exc}"
    assert True
    service.delete_table()

As you can see, it can get a little tedious if you have a lot of test cases to write with a start and end common functionality.

Conclusion

moto is an amazing library to mock any AWS Dynamo DB based calls. You can check out the development on their GitHub page.

A trivia, prior to the moto library version 3.1.0, the mock decorator to be used was @mock_dynamodb2. Make sure if you are using the version prior to 3.1.0, use this decorator instead or update to the version I used in this blog.

DEV Community: Syed Mohammad Ibrahim

Code Review Exercises That Actually Work: Python Edition (Junior to Senior)

Why Code Reviews in Python Interviews Matter

Python Style Guide for Code Review Exercises

✅ Code Style & Structure

🔒 Error Handling

📦 Code Organization

🧪 Testability

🧼 Clean Code

Junior-Level Code Review Example

Code Snippet:

Issues to Spot:

Follow-up Prompt:

Mid-Level Code Review Example

Code Snippet:

Issues to Spot:

Follow-up Prompt:

Senior-Level Code Review Example

Code Snippet:

Issues to Spot:

Follow-up Prompt:

Interviewer Tips

What’s Next

Code Review Exercises That Actually Work: Java Edition (Junior to Senior)

Why Code Reviews Belong in Interviews

Java Style Guide for Code Review Exercises

✅ Code Style & Structure

🔐 Exception Handling

🧼 Clean Code

🔍 Input & Output

🚦 Testability

Junior-Level Code Review Example

Code Snippet:

What to Look For:

Optional Follow-up Prompt:

Mid-Level Code Review Example

Code Snippet:

What to Look For:

Follow-up Prompt:

Senior-Level Code Review Example

Code Snippet:

What to Look For:

Follow-up Prompt:

Tips for Interviewers

Coming Up Next: Python, JavaScript, and More

Rethinking Tech Interviews: Real Skills, Real Projects, No Bullshit

Introduction

1. Start with a GitHub (or GitLab) Project Walkthrough

2. Ask Role-Relevant Technical Questions (No Trivia)

3. Code Review + Refactor: Test How They Think About Bad Code

4. Realistic Coding Task — AI Allowed

Bonus: Soft Skills Appear Naturally

Conclusion: A Better Interview Framework

02. Software Engineering Design & Security Principles

Design Problems

Software Design

Impact of Design Principles on Security

NIST Special Publication 800-160, Volume 1 Revision 1

Security Principles

Weakness

Attack Surface

Attack Vector

Illustration

Typical Security Objectives

Other Security Objectives

Set of Security Principles

Trustworthiness vs. Trust[4]

Security Principle - Defence in Depth

Security Principle - Keep Security Simple

Security Principle - Attack Surface Reduction

Security Principle - Establish Secure Defaults

Security Principle - Principle of Least Privilege

Security Principle - Fail Securely

Security Principle - Complete Mediation ("Non-Passable")

Security Principle - Don't Trust Service Interface

Security Principle - Separation of Duties/Privilege

Security Principle - Avoid Security Through Obscurity

Security Principle - Avoid Non-Atomic Security Operations

Security Principle - Fix Security Issues Correctly

Security Principle - Least Common 'Security' Mechanism

Trustworthiness vs. Trust^[4]